Apparatus and methods for monitoring and optimizing delivery of content in a network

ABSTRACT

Methods and apparatus for delivering content to a user so as to optimize and enhance the “experience” of the content. In one embodiment, an optimization and monitoring entity (OME) is used which determines, evaluates, and provides notification and/or recommendation of alternative content delivery platforms which are available to a user. The OME receives requests for content forwarded from a content server containing information identifying requesting devices and/or subscriber accounts. The OME examines the capabilities of the registered devices, and identifies/recommends alternative devices based on e.g., video/audio quality, picture size, bandwidth availability, and/or any other additional capabilities of the client devices. A notification is then sent to the client devices indicating which of the user’s devices may receive the content alternatively, or in addition to, the requesting device. The notifications may be interactive, allowing the user to select one or more of the devices for delivery.

RELATED APPLICATIONS

This application is related to co-owned, co-pending U.S. Pat.Application Serial Nos. 12/536,724 filed on Aug. 6, 2009 and entitled“SYSTEM AND METHOD FOR MANAGING ENTITLEMENTS TO DATA OVER A NETWORK”,and 61/256,903 filed on Oct. 30, 2009 and entitled “METHODS ANDAPPARATUS FOR PACKETIZED CONTENT DELIVERY OVER A CONTENT DELIVERYNETWORK, each of which is incorporated herein by reference in itsentirety.

COPYRIGHT

A portion of the disclosure of this patent document contains materialthat is subject to copyright protection. The copyright owner has noobjection to the facsimile reproduction by anyone of the patent documentor the patent disclosure, as it appears in the Patent and TrademarkOffice patent files or records, but otherwise reserves all copyrightrights whatsoever.

BACKGROUND OF THE INVENTION 1. Field of Invention

The present invention relates generally to the field of optimizing theoperation of a content delivery network such as for example a cable,Hybrid Fiber Copper (HFCu), or satellite network. More particularly, thepresent invention is in one exemplary aspect related to apparatus andmethods for monitoring and optimizing delivery of programs includingacross a plurality of delivery platforms.

2. Description of Related Technology

Recent advances in digital information processing and technology havemade a whole range of services and functions available for delivery toconsumers at various types devices for very reasonable prices orsubscription fees. These services and functions include digital contentor programming (movies, etc.), digital video-on-demand (VOD), personalvideo recorder (PVR) and networked PVR (nPVR), Internet Protocoltelevision (IPTV), digital media playback and recording, as well highspeed Internet access (including so-called “Internet TV”, wheretelevision programming is delivered over the Internet without QoS) andIP-based telephony (e.g., VoIP). Other services available to networkusers include access to, and recording of, digital music (e.g., MP3files).

Currently, many of these services are provided to the user via a widevariety of different equipment environments and delivery paradigmsincluding, inter alia, cable or satellite modems or QAMs, HFCu (i.e.,Hybrid Fiber-copper distribution via indigenous POST/PSTN wiring in apremises), Wi-Fi™ hubs, Ethernet hubs, gateways, switches, and routers,to a plurality of user equipment types. For example, content may bedelivered to users at set-top boxes, personal (desktop) computers,laptop computers, other mini-computers (such as so-called “netbooks”,mini-notebook computers), and/or other devices. Recent advances inconsumer electronics have also led to the widespread introduction of avariety of portable media devices (PMDs) such as, inter alia, portabledigital music devices such as the well known Apple iPod™ and otherso-called “MP3 players”, cellular telephones/smartphones, handheldcomputers, and personal digital assistants (PDA), which allow users tostore and playback audio and video files.

Although a myriad of services, equipment, data formats and providers areavailable, current systems offer little to no interoperability or“intelligent” interrelationship between devices. The request for andplayback of audio and video files from a first device is often limitedto playback via the device itself. In other words, a user may utilize adevice to only select delivery of audio and video files to be playedback on that same device. Thus, if a user requests video content, theuser is often limited to delivery of the requested content to thatdevice. Further, the request messages are frequently determined by aspecific protocol tied to the device or software that maybe incompatiblewith other device and software protocols thereby creatingincompatibility issues. Current technology allows one device to browsethe directory structure of other compatible devices (see, e.g., DLNAtechnology); however, there is no real intelligence or over-archingcognizance of the relationship of all of the devices associated with agiven user or subscriber account, and their relationship to differenttypes of content available over the various networks or deliveryparadigms.

Nor is their any analysis of what devices or combinations of devices,encodings, etc. would give the user the best “experience” with respectto given content, including consideration of user-specific preferences.Rather, extant solutions are generally completely passive, and take noactive role in evaluating, recommending, or selecting content formats,delivery modes or user platforms and translating multiprotocol messagerequests.

Therefore, what are needed are improved apparatus and methods fordistributing content to a plurality of a user premises and PMD devices.Such improved apparatus and services would ideally, upon user requestfor content, provide users with recommendations for optimizing theuser’s experience and/or the network workload. For example, mechanismswould be provided to exploit the various features of the different onesof the user’s available devices, as well as that user’s deliverypreferences.

Moreover, it would be desirable to permit the user to view their contentanywhere (and on any device) they desire, at any given time, includingthe ability to transfer extant content “sessions” between differentdevices, the latter which may include heterogeneous hardware/softwareenvironments.

SUMMARY OF THE INVENTION

The present invention satisfies the foregoing needs by providing, interalia, improved apparatus and methods for optimization and monitoring ofcontent delivery, including monitoring and optimizing content deliveryacross a plurality of delivery platforms associated with a single useror premises.

In a first aspect of the invention, a method for providing content isdisclosed. In one embodiment, the content delivery network comprises atleast one content server, a protocol translation server, a database, anda plurality of client devices, and the method comprises: receiving arequest for content from one of the plurality of client devices;determining a subscriber account to which the one client device issuingthe request has been registered; identifying at least one other devicein the database also registered to the subscriber account; and causinggeneration of a notification for display on the one requesting clientdevice, the notification showing or listing the at least one otherdevice.

In one variant, the identifying at least one other device comprisesidentifying the at least one other device based on its ability tosuitably render the requested content.

In another variant, the identifying at least one other device comprisesidentifying the at least one other device based on its ability tosuitably render the requested content better than the one client device.

In a further variant, the identifying at least one other devicecomprises identifying the at least one other device based on its currentavailability for display of the requested content. The identifying atleast one other device comprises further identifying the at least oneother device based on its ability to render the requested content betterthan the one client device.

In another variant, the protocol translation server accepts message fromthe client in the client native messaging protocol and translate themessaging to other protocols to bridge messaging between other clients,servers or other equipment in the delivery of content.

In another variant, if the determining indicates that the one requestingclient device is not registered to a subscriber account, registering theclient device to a subscriber account. The registration comprises e.g.,receiving information identifying the client device and the subscriberaccount; associating the client device to the subscriber account; andstoring the association in the database. The information identifying theclient device comprises at least one of a MAC address and/or an IPaddress, and the information identifying the subscriber accountcomprises at least one of an account number and a login-passwordcombination.

In yet another variant, the act of determining comprises utilizing acryptographic hash of a piece of information uniquely identifying theone requesting client device, and matching this to a corresponding hashwithin the database.

In still another variant, the notification is further configured toenable a user of the requesting client device to select one or more ofthe at least one other devices for delivery of content thereto.

In yet another variant, the method further comprises: generating agraphical display having representations of at least the one clientdevice and the at least one other device; and allowing the user toselect at least one of the devices via the display.

In a second aspect of the invention, apparatus for use in a contentdelivery network is disclosed. In one embodiment, the apparatuscomprises: a network interface configured to communicate with aplurality of network entities; a storage apparatus; and a digitalprocessor configured to run at least one computer program thereon. Whenexecuted, the computer program: monitors content requests from aplurality of user devices, each content request comprising informationidentifying an individual one of the plurality of user devices;identifies a subscriber account associated with the individual userdevice; identifies a plurality of additional user devices alsoassociated with the identified subscriber account; and generates anotification message to send to the individual user device, thenotification messages presenting a user of the individual user devicewith one or more options for delivery of the requested content to theplurality of identified additional devices.

In one variant, the content delivery network comprises a cabletelevision network having at least one content distribution serverconfigured to service the content requests, the content distributionserver being in data communication with the apparatus via the networkinterface.

In another variant, the storage apparatus is in communication with theprocessor and configured to store a plurality of records, the recordsidentifying a plurality of subscriber accounts and at least one userdevice associated with each. The plurality of records are updated basedat least in part on information received from e.g., a billing entity ofthe network, and/or information received from the user devices.

In yet another variant, the content requests comprise SIP (SessionInitiation Protocol) requests, and the plurality of user devicescomprise IP-enabled client devices adapted to support the SIP protocol.

In a further variant, the plurality of identified additional devices arelisted in the notification message according to a hierarchy, thehierarchy being determined based on one or more criteria. The criteriacomprise e.g., at least: (i) device capabilities; and (ii) userpreferences.

In a third aspect of the invention, a method of providing content to aplurality of client devices is disclosed. In one embodiment, the devicesare each registered to a subscriber account, and the method comprises:receiving a request for content from a first one of the plurality ofclient devices; determining a subscriber account to which the requestingclient device is registered; identifying a second one of the pluralityof client devices also registered to the subscriber account; andgenerating a notification for display on the first and the second clientdevices, the notification enabling a user of the first and the secondclient devices to select delivery of content at one or more of the firstand the second client devices.

In one variant, the request comprises at least information uniquelyidentifying the first client device (e.g., IP address or a MAC address).

In another variant, the act of determining the subscriber accountcomprises querying a database using at least the information uniquelyidentifying the first client device, the database comprising anassociation of each of the plurality of client devices to a subscriberaccount; and the act of identifying the second client device comprisesextracting the association from the database.

In yet another variant, the request comprises at least informationidentifying the subscriber account; e.g., at least one of: (i) anaccount number, and (ii) a log-in and password combination. Informationis extracted from the request, and the act of identifying the secondclient devices comprises querying a database using at least theinformation identifying the subscriber account, the database comprisingan association of each of the plurality of client devices to asubscriber account.

In still another variant, the notification is configured to enable auser of the first and the second client devices to select delivery ofcontent at only those of the first and the second client devices havingone more desired characteristics.

In a fourth aspect of the invention, a computer readable apparatus isdisclosed. In one embodiment, the apparatus comprises a medium adaptedto store a computer program for the optimized delivery of content in anetwork, the computer program comprising instructions which, whenexecuted: determine an association between a plurality of client devicesto a single subscriber account; obtain content requests, one of thecontent requests relating to a request for content at a first one of theplurality of client devices; evaluate one or more aspects of theplurality of client devices; based on the evaluation, selects one ormore of the plurality client devices as delivery platforms for therequested content; and present information regarding the selected one ormore client devices to a user of the first client device.

In one variant, the computer program is further configured to receive auser selection of at least one of the selected client devices fordelivery of the requested content.

In another variant, the content requests are forwarded from at least onecontent distribution server.

In yet another variant, the presentation of information regarding theselected client devices includes the first client device, and comprisesa notification or message sent to at least the first client device fordisplay on a display device associated therewith.

In a further variant, the one or more aspects comprise at least one of:device capabilities; user preferences; and bandwidth requirements.

In yet another variant, the selection of one or more of the pluralityclient devices as delivery platforms for the requested content comprisesselection based at least in part on providing a higher video picturequality than that available with the first one of the client devices.

In a further variant, the selection of one or more of the pluralityclient devices as delivery platforms for the requested content comprisesselection based at least in part on providing a higher quality audioexperience than that available with the first one of the client devices.

In a fifth aspect of the invention, headend apparatus for use in acontent delivery network is disclosed. In one embodiment, the networkcomprises at least one content server and a database comprising aplurality of records associating each of a plurality of user devices tosubscriber accounts, and the apparatus comprises: a network interfaceconfigured to receive content requests directly or indirectly from theplurality of user devices; a storage apparatus; and a digital processorconfigured to run at least one computer program thereon and configuredto, when executed: examine the content requests to identify subscriberaccounts associated with each request; query the database to identify aplurality of user devices associated with a particular one of thesubscriber accounts of a particular one of the content requests;evaluate one or more aspects of the identified plurality of userdevices; based at least in part on the evaluation, select one or more ofthe plurality of identified user devices as delivery platforms for therequested content; and present the selected one or more of the pluralityof identified user devices to a user.

In a sixth aspect of the invention, a method of operating a contentdelivery apparatus is disclosed. In one embodiment, the methodcomprises: establishing a communication session between a content sourceand a first recipient device using a session-based protocol adapted foruse on a packet-switched network; transferring packetized content to thefirst recipient device within the session; establishing a communicationsession between the content source and a second recipient device; andswitching delivery of the packetized content to the second recipientdevice from the first device.

In one variant, the content source comprises an IP TV (Internet Protocoltelevision) server disposed within a content delivery network.

In another variant, the content delivery network comprises a HybridFiber coaxial (HFC) cable television network, and the packetized contentis delivered according to a unicast session over the HFC network via oneor more QAM channels.

In yet another variant, the communication session established betweenthe content source and the first recipient device, and the communicationsession established between the content source and the second recipientdevice, comprise the same communication session.

In a further variant, the method further comprises: associating thefirst recipient device and the second recipient device within a databaseof a network operator; and based at least in part on the association,notifying a user of the first recipient device that the second recipientdevice is available for receipt of the packetized content.

In another variant, the switching delivery of the packetized content tothe second recipient device from the first device comprises thefollowing steps, performed substantially and without further userintervention: suspending display of the packetized content on the firstrecipient device or a display device associated therewith; recording, onpremises recording device, a portion of the packetized content deliveredduring the suspension; resuming the display of the packetized content onthe second recipient device or a display device associated therewith ata later time; and giving the user the option to resume display of thepacketized content starting with the recorded portion.

In another variant, the switching delivery of the packetized content tothe second recipient device from the first device comprises thefollowing steps, performed substantially and without further userintervention: suspending display of the packetized content on the firstrecipient device or a display device associated therewith, thesuspending comprising suspending delivery of the packetized content to apremises where the first recipient is located; resuming the display ofthe packetized content on the second recipient device or a displaydevice associated therewith at a later time, the resuming comprisingresuming delivery of the packetized content substantially at the pointwithin the packetized content where the suspending was invoked.

In yet another variant, if the content is real-time streaming, streamingto the second device begins as soon as possible after streaming to thefirst device ceases. This may be useful for example, in cases wherelicensing requires that only one endpoint is active at a given instantor only one session may exist at a time.

In another variant, the user may be able to manually configure a mediadevice that is not capable of automatic negotiation via an interface.

Other features and advantages of the present invention will immediatelybe recognized by persons of ordinary skill in the art with reference tothe attached drawings and detailed description of exemplary embodimentsas given below.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a functional block diagram illustrating an exemplary HFC cablenetwork configuration useful with the present invention.

FIG. 1 a is a functional block diagram illustrating one exemplary HFCcable network headend configuration useful with the present invention.

FIG. 1 b is a functional block diagram illustrating one exemplary localservice node configuration useful with the present invention.

FIG. 1 c is a functional block diagram illustrating one exemplarybroadcast switched architecture (BSA) network useful with the presentinvention.

FIG. 1 d is a functional block diagram illustrating one exemplarypacketized content delivery network architecture useful with the presentinvention.

FIG. 2 is a functional block diagram illustrating a network architectureuseful with the present invention.

FIG. 2 a is a functional block diagram illustrating another networkarchitecture useful with the present invention.

FIG. 2 b is a functional block diagram illustrating yet another networkarchitecture useful with the present invention.

FIG. 2 c is a functional block diagram illustrating an exemplary useraccount and device database.

FIG. 3 a is a logical flow diagram illustrating one embodiment of amethod for monitoring and optimizing content delivery according to thepresent invention.

FIG. 3 b is a logical flow diagram illustrating one embodiment of amethod for monitoring and optimizing content delivery according to thepresent invention.

FIG. 4 is a logical flow diagram illustrating one embodiment of ageneralized method for inter-device session transfer according to theinvention.

FIG. 4 a is a logical flow diagram illustrating one SIP-basedimplementation of the generalized method of FIG. 4 .

FIG. 5 is a functional block diagram illustrating one embodiment of aoptimizing and monitoring entity (OME) according to the presentinvention.

FIG. 6 is a functional block diagram illustrating one embodiment of aconsumer or client device for use in the present invention.

DETAILED DESCRIPTION OF THE INVENTION

Reference is now made to the drawings wherein like numerals refer tolike parts throughout.

As used herein, the term “application” refers generally to a unit ofexecutable software that implements a certain functionality or theme.The themes of applications vary broadly across any number of disciplinesand functions (such as on-demand content management, e-commercetransactions, brokerage transactions, home entertainment, calculatoretc.), and one application may have more than one theme. The unit ofexecutable software generally runs in a predetermined environment; forexample, the unit could comprise a downloadable Java XIet™ that runswithin the JavaTV™ environment.

As used herein, the term “computer program” or “software” is meant toinclude any sequence or human or machine cognizable steps which performa function. Such program may be rendered in virtually any programminglanguage or environment including, for example, C/C++, Fortran, COBOL,PASCAL, assembly language, markup languages (e.g., HTML, SGML, XML,VoXML), and the like, as well as object-oriented environments such asthe Common Object Request Broker Architecture (CORBA), Java™ (includingJ2ME, Java Beans, etc.), Binary Runtime Environment (e.g., BREW), andthe like.

The terms “Customer Premises Equipment (CPE)” refer to any type ofelectronic equipment located within a customer’s or user’s premises andconnected to a network, including devices having access to digitaltelevision content via a satellite, cable, or terrestrial network. Theterm “customer premises equipment” (CPE) includes such electronicequipment such as set-top boxes (e.g., DSTBs), televisions, cable modems(CMs), embedded multimedia terminal adapters (eMTAs), whetherstand-alone or integrated with other devices, Digital Video Recorders(DVR), gateway storage devices (e.g., Furnace), and ITV PersonalComputers.

As used herein, the term “display” means any type of device adapted todisplay information, including without limitation: CRTs, LCDs, TFTs,plasma displays, LEDs, incandescent and fluorescent devices. Displaydevices may also include less dynamic devices such as, for example,printers, e-ink devices, and the like.

As used herein, the term “DOCSIS” refers to any of the existing orplanned variants of the Data Over Cable Services InterfaceSpecification, including for example DOCSIS versions 1.0, 1.1, 2.0 and3.0. DOCSIS (version 1.0) is a standard and protocol for internet accessusing a “digital” cable network.

As used herein, the term “DVR” (digital video recorder) refers generallyto any type of recording mechanism and/or software environment, locatedin the headend, the user premises or anywhere else, whereby content sentover a network can be recorded and selectively recalled. Such DVR may bededicated in nature, or part of a non-dedicated or multi-functionsystem.

As used herein, the term “headend” refers generally to a networkedsystem controlled by an operator (e.g., an MSO or multiple systemsoperator) that distributes programming to MSO clientele using clientdevices. Such programming may include literally any informationsource/receiver including, inter alia, free-to-air TV channels, pay TVchannels, interactive TV, and the Internet.

As used herein, the terms “Internet” and “internet” are usedinterchangeably to refer to inter-networks including, withoutlimitation, the Internet.

As used herein, the term “memory” includes any type of integratedcircuit or other storage device adapted for storing digital dataincluding, without limitation, ROM. PROM, EEPROM, DRAM, SDRAM, DDR/2SDRAM, EDO/FPMS, RLDRAM, SRAM, “flash” memory (e.g., NAND/NOR), andPSRAM.

As used herein, the terms “microprocessor” and “digital processor” aremeant generally to include all types of digital processing devicesincluding, without limitation, digital signal processors (DSPs), reducedinstruction set computers (RISC), general-purpose (CISC) processors,microprocessors, gate arrays (e.g., FPGAs), PLDs, reconfigurable computefabrics (RCFs), array processors, secure microprocessors, andapplication-specific integrated circuits (ASICs). Such digitalprocessors may be contained on a single unitary IC die, or distributedacross multiple components.

As used herein, the terms “MSO” or “multiple systems operator” refer toa cable, fiber to the home (FTTH), fiber to the curb (FTTC), satellite,or terrestrial network provider having infrastructure required todeliver services including programming and data over those mediums.

As used herein, the terms “network” and “bearer network” refer generallyto any type of telecommunications or data network including, withoutlimitation, hybrid fiber coax (HFC) networks, satellite networks, telconetworks, and data networks (including MANs, WANs, LANs, WLANs,internets, and intranets). Such networks or portions thereof may utilizeany one or more different topologies (e.g., ring, bus, star, loop,etc.), transmission media (e.g., wired/RF cable, RF wireless, millimeterwave, optical, etc.) and/or communications or networking protocols(e.g., SONET, DOCSIS, IEEE Std. 802.3, ATM, X.25, Frame Relay, 3GPP,3GPP2, WAP, SIP, UDP, FTP, RTP/RTCP, H.323, etc.).

As used herein, the term “network interface” refers to any signal, data,or software interface with a component, network or process including,without limitation, those of the FireWire (e.g., FW400, FW800, etc.),USB (e.g., USB2), Ethernet (e.g., 10/100, 10/100/1000 (GigabitEthernet), 10-Gig-E, etc.), MoCA, Serial ATA (e.g., SATA, e-SATA,SATAII), Ultra-ATA/DMA, Coaxsys (e.g., TVnet™), radio frequency tuner(e.g., in-band or OOB, cable modem, etc.), Wi-Fi (802.11a,b,g,n), WiMAX(802.16), PAN (802.15), or IrDA families.

As used herein, the term “QAM” refers to modulation schemes used forsending signals over cable networks. Such modulation scheme might useany constellation level (e.g. QPSK, QAM-16, QAM-64, QAM-256 etc.)depending on details of a cable network. A QAM may also refer to aphysical channel modulated according to the schemes.

As used herein, the term “server” refers to any computerized component,system or entity regardless of form which is adapted to provide data,files, applications, content, or other services to one or more otherdevices or entities on a computer network.

As used herein, the term “service”, “content”, “program” and “stream”are sometimes used synonymously to refer to a sequence of packetizeddata that is provided in what a subscriber may perceive as a service. A“service” (or “content”, or “stream”) in the former, specialized sensemay correspond to different types of services in the latter,non-technical sense. For example, a “service” in the specialized sensemay correspond to, among others, video broadcast, audio-only broadcast,pay-per-view, or video-on-demand. The perceivable content provided onsuch a “service” may be live, pre-recorded, delimited in time,undelimited in time, or of other descriptions. In some cases, a“service” in the specialized sense may correspond to what a subscriberwould perceive as a “channel” in traditional broadcast television.

As used herein, the term “storage device” refers to without limitationcomputer hard drives, DVR device, memory, RAID devices or arrays,optical media (e.g., CD-ROMs, Laserdiscs, Blu-Ray, etc.), or any otherdevices or media capable of storing content or other information.

As used herein, the term “user interface” refers to, without limitation,any visual, graphical, tactile, audible, sensory, or other means ofproviding information to and/or receiving information from a user orother entity.

As used herein, the term “Wi-Fi” refers to, without limitation, any ofthe variants of IEEE-Std. 802.11 or related standards including 802.11a/b/g/n.

As used herein, the term “wireless” means any wireless signal, data,communication, or other interface including without limitation Wi-Fi,Bluetooth, 3G, HSDPA/HSUPA, TDMA, CDMA (e.g., IS-95A, WCDMA, etc.),FHSS, DSSS, GSM, PAN/802.15, WiMAX (802.16), 802.20, narrowband/FDMA,OFDM, PCS/DCS, analog cellular, CDPD, satellite systems, millimeter waveor microwave systems, acoustic, and infrared (i.e., IrDA).

Overview

The present invention discloses, inter alia, methods and apparatus foroptimizing content delivery to multiple user devices. One salientfunctionality of the present invention is to provide the user (e.g., asubscriber of am IP, cable or satellite network) with the best possible“user experience” at all times, depending on the varioushardware/software environments they have available to them, and theircurrent usage needs and preferences.

In one embodiment, an optimization and monitoring entity (OME) isutilized in conjunction with other network and user premises componentsto provide the aforementioned functionality. The OME comprises one ormore software applications which work in conjunction with one another(and with one or more content servers) to determine, evaluate, andprovide notification to a user of one or more alternative contentdelivery platforms, such as for example when a request for content isreceived. Alternative services, transports, and delivery models, mayalso be recommended in another variant of the invention.

In one exemplary use case, requests for content are received at acontent server, and forwarded to the OME. The content server may satisfythe request, or may first require selection of a delivery platform.Information identifying the requesting device (such as IP address, MACaddress, etc.) and/or the subscriber account or specific user (such asaccount number, physical address, login/password information, etc.) isderived from or embedded in the content requests (or otherwise retrievedfrom information contained within the request). The OME uses thecollected information to determine whether the requesting device isregistered to a known user account by comparing the identification to adatabase of registered accounts and devices. The OME uses theaforementioned database to compile a list of all of the other knownclient devices in a specific user’s account. Software applicationsrunning on the OME further differentiate the various features andcapabilities of the different types of client devices registered to auser account and which may be used to receive content. In one variant,the OME comprises a “recommendation engine” that determines whetherrequested content may be provided to the same user on a differentplatform; e.g., on a different one of the client devices associated withthe user’s account. Such an alternative device may be recommended basedon e.g., video/audio quality, picture size, bandwidth availability,and/or any other additional capabilities of the recommended clientdevice, or may be recommended based on historical usage or otherinformation about the user (or a specification of user preferencesassociated with the account and accessed by the OME).

In one implementation, a list of the alternative delivery platformsand/or modes is presented to a user via a notification generated by theOME (or generated by the CPE after being triggered by the OME). Thenotifications sent to the client device(s) indicate which, if any, ofthe user’s other devices may receive the content alternatively (or inaddition to) the content being received at the requesting device. Thenotifications generated/triggered by the OME may, in one embodiment, beinteractive in nature and provide a user the ability to select one ormore of the presented content delivery platforms, as well as features orconfigurations associated therewith.

The client devices requesting content and/or being recommended for thedelivery of content may include, inter alia, consumer premises devices(CPE) 106 (such as digital set top boxes (STB), IPTV devices, mediabridges (MB), converged premises devices (CPD), etc.), personal videorecorders (PVR), digital video recorders (DVR), network DVR, computerdevices (such as personal computers (PC) and laptop computers), andmobile devices (including personal media devices (PMD) and mobiletelephones). In one variant of the invention (so-called “chain mode”),the recommendation engine evaluates two or more communicating clientdevices along a “rendering path” to determine the ultimate deliveryconfiguration to the user (e.g., to prevent instances where the firstdevice encountered in the chain provides the recommendation engine witha false representation of the quality of the entire rendering chain ofdevices).

In another aspect of the invention, a centralized control device isdisclosed which permits the transfer or migration of content deliverysessions (e.g., SIP-based IPTV sessions or the like) between two or moredevices. In one implementation, the user’s premises gateway or DSTB orPC is used as the host device for a user interface which shows thevarious premises (and “off-net”) devices associated with theuser/subscriber account, and their interconnectivity. GUI functionality(e.g., a multi-touch-screen GUI, drag-and-drop, speech recognitionapplication, or other interface/input device) allows the user to rapidlydesignate particular devices for communication and establishment of asession/delivery of content, and/or transfer existing communicationsessions between capable devices (such as may be determined by the OMErecommendation engine).

Methods for utilization of the foregoing functionality, and a businessrules engine for directing or adjusting the use of the optimizationprocess, are also described herein.

Detailed Description of Exemplary Embodiments

Exemplary embodiments of the apparatus and methods of the presentinvention are now described in detail. While these exemplary embodimentsare described in the context of the aforementioned hybrid fiber coax(HFC) cable system architecture having an multiple systems operator(MSO), digital networking capability, and plurality of client devices,the general principles and advantages of the invention may be extendedto other types of networks and architectures, whether broadband,narrowband, wired or wireless, or otherwise, the following thereforebeing merely exemplary in nature. For example, a satellite receiver anddelivery network, or alternatively an IP-based delivery network may beutilized. A WiMAX (IEEE Std. 802.16) broadband delivery network ortransport could also be utilized. Hence, the optimization techniquesdiscussed herein are largely agnostic to the delivery network used toprovide content, as described in greater detail below.

It will also be appreciated that while described generally in thecontext of a consumer (i.e., home) end user domain or premises, thepresent invention may be readily adapted to other types of environments(e.g., commercial/enterprise, government/military, healthcare facility,etc.) as well. Myriad other applications are possible.

It is further noted that while described primarily in the context of acable delivery system with 6 MHz RF channels, the present invention isapplicable to literally any network topology or paradigm, and anyfrequency/bandwidth, such as for example 8 MHz channels. Furthermore, asreferenced above, the invention is in no way limited to traditionalcable system frequencies (i.e., below 1 GHz), and in fact may be usedwith systems that operate above 1 GHz band in center frequency orbandwidth, to include without limitation so-called ultra-widebandsystems.

Also, while certain aspects are described primarily in the context ofthe well-known IP or Internet Protocol (described in, inter alia, RFC791 and 2460), it will be appreciated that the present invention mayutilize other types of protocols (and in fact bearer networks to includeother internets and intranets) to implement the described functionality.

In a further embodiment, if the content is real-time streaming,streaming to the second device may begin as soon as possible afterstreaming to the first device ceases. This may be useful in cases wherelicensing requires that only one endpoint is active at a given instant.

In another aspect, a web portal like interface may provide an option tomanually configure a media device that is not capable of automaticnegotiation. This may be done by a user selecting a device class from amenu, then a manufacturer, then a model type and version. Thisinteraction then indicates that the device is accepted or supported andstreaming commences.

Other features and advantages of the present invention will immediatelybe recognized by persons of ordinary skill in the art with reference tothe attached drawings and detailed description of exemplary embodimentsas given below.

Network

FIG. 1 illustrates a typical content delivery network configuration withwhich the apparatus and methods of the present invention may be used.The various components of the network 100 include (i) one or more dataand application origination points 102; (ii) one or more content sources103, (iii) one or more application distribution servers 104; (iv) one ormore VOD servers 105, and (v) customer premises equipment (CPE) 106. Thedistribution server(s) 104, VOD servers 105 and CPE(s) 106 are connectedvia a bearer (e.g., HFC) network 101. A simple architecture comprisingone of each of the aforementioned components 102, 104, 105, 106 is shownin FIG. 1 for simplicity, although it will be recognized that comparablearchitectures with multiple origination points, distribution servers,VOD servers, and/or CPE devices (as well as different networktopologies) may be utilized consistent with the invention. For example,the headend architecture of FIG. 1 a (described in greater detail below)may be used.

The data/application origination point 102 comprises any medium thatallows data and/or applications (such as a VOD-based or “Watch TV”application) to be transferred to a distribution server 104. This caninclude for example a third party data source, application vendorwebsite, CD-ROM, external network interface, mass storage device (e.g.,RAID system), etc. Such transference may be automatic, initiated uponthe occurrence of one or more specified events (such as the receipt of arequest packet or ACK), performed manually, or accomplished in anynumber of other modes readily recognized by those of ordinary skill.

The application distribution server 104 comprises a computer systemwhere such applications can enter the network system. Distributionservers are well known in the networking arts, and accordingly notdescribed further herein.

The VOD server 105 comprises a computer system where on-demand contentcan be received from one or more of the aforementioned data sources 102and enter the network system. These servers may generate the contentlocally, or alternatively act as a gateway or intermediary from adistant source.

The CPE 106 includes any equipment in the “customers’ premises” (orother locations, whether local or remote to the distribution server 104)that can be accessed by a distribution server 104. As will be discussedin greater detail below, other consumer devices may be utilized inconjunction with or in lieu of the CPE 106. Also discussed below, theCPE 106 of FIG. 1 -1d may be more broadly referred to throughout thepresent application as client devices 206.

Referring now to FIG. 1 a , one exemplary embodiment of a headendarchitecture useful with the present invention is described. As shown inFIG. 1 a , the headend architecture 150 comprises typical headendcomponents and services including billing module 152, subscribermanagement system (SMS) and CPE configuration management module 154,cable-modem termination system (CMTS) and OOB system 156, as well asLAN(s) 158, 160 placing the various components in data communicationwith one another. It will be appreciated that while a bar or bus LANtopology is illustrated, any number of other arrangements as previouslyreferenced (e.g., ring, star, etc.) may be used consistent with theinvention. It will also be appreciated that the headend configurationdepicted in FIG. 1 a is high-level, conceptual architecture and thateach MSO may have multiple headends deployed using custom architectures.

The architecture 150 of FIG. 1 a further includes amultiplexer/encrypter/modulator (MEM) 162 coupled to the HFC network 101adapted to “condition” content for transmission over the network. Thedistribution servers 104 are coupled to the LAN 160, which providesaccess to the MEM 162 and network 101 via one or more file servers 170.The VOD servers 105 are coupled to the LAN 160 as well, although otherarchitectures may be employed (such as for example where the VOD serversare associated with a core switching device such as an 802.3z GigabitEthernet device). As previously described, information is carried acrossmultiple channels. Thus, the headend must be adapted to acquire theinformation for the carried channels from various sources. Typically,the channels being delivered from the headend 150 to the CPE 106(“downstream”) are multiplexed together in the headend and sent toneighborhood hubs via a variety of interposed network components.

Content (e.g., audio, video, data, files, etc.) is provided in eachdownstream (in-band) channel associated with the relevant service group.To communicate with the headend or intermediary node (e.g., hub server),the CPE 106 may use the out-of-band (OOB) or DOCSIS channels andassociated protocols. The OCAP 1.0, 2.0, 3.0 (and subsequent)specification provides for exemplary networking protocols bothdownstream and upstream, although the invention is in no way limited tothese approaches.

It will also be recognized that the multiple servers (broadcast, VOD, orotherwise) can be used, and disposed at two or more different locationsif desired, such as being part of different server “farms”. Thesemultiple servers can be used to feed one service group, or alternativelydifferent service groups. In a simple architecture, a single server isused to feed one or more service groups. In another variant, multipleservers located at the same location are used to feed one or moreservice groups. In yet another variant, multiple servers disposed atdifferent location are used to feed one or more service groups.

“Switched” Networks

FIG. 1 c illustrates an exemplary “switched” network architecture alsouseful with the present invention. While a so-called “broadcast switchedarchitecture” or BSA network is illustrated in this exemplaryembodiment, it will be recognized that the present invention is in noway limited to such architectures.

Switching architectures allow improved efficiency of bandwidth use forordinary digital broadcast programs. Ideally, the subscriber is unawareof any difference between programs delivered using a switched networkand ordinary streaming broadcast delivery.

FIG. 1 c shows the implementation details of one exemplary embodiment ofthis broadcast switched network architecture. Specifically, the headend150 contains switched broadcast control and media path functions 190,192; these element cooperating to control and feed, respectively,downstream or edge switching devices 194 at the hub site which are usedto selectively switch broadcast streams to various service groups. A BSAserver 196 is also disposed at the hub site, and implements functionsrelated to switching and bandwidth conservation (in conjunction with amanagement entity 198 disposed at the headend). An optical transportring 197 is utilized to distribute the dense wave-division multiplexed(DWDM) optical signals to each hub in an efficient fashion.

Co-owned and co-pending U.S. Pat. Application Serial No. 09/956,688filed Sep. 20, 2001 and entitled “Technique for Effectively ProvidingProgram Material in a Cable Television System”, incorporated herein byreference in its entirety, describes one exemplary broadcast switcheddigital architecture useful with the present invention, although it willbe recognized by those of ordinary skill that other approaches andarchitectures may be substituted.

In addition to “broadcast” content (e.g., video programming), thesystems of FIGS. 1 a and 1 c also deliver Internet data services usingthe Internet protocol (IP), although other protocols and transportmechanisms of the type well known in the digital communication art maybe substituted. One exemplary delivery paradigm comprises deliveringMPEG-based video content, with the video transported to user PCs (orIP-based DSTBs) over the aforementioned DOCSIS channels comprising MPEG(or other video codec such as H.264 or AVC) over IP over MPEG. That is,the higher layer MPEG- or other encoded content is encapsulated using anIP protocol, which then utilizes an MPEG packetization of the type wellknown in the art for delivery over the RF channels. In this fashion, aparallel delivery mode to the normal broadcast delivery exists; i.e.,delivery of video content both over traditional downstream QAMs to thetuner of the user’s STB or other receiver device for viewing on thetelevision, and also as packetized IP data over the DOCSIS QAMs to theuser’s PC or other IP-enabled device via the user’s cable modem.

Referring again to FIG. 1 c , the IP packets associated with Internetservices are received by edge switch 194, and forwarded to the cablemodem termination system (CMTS) 199. The CMTS examines the packets, andforwards packets intended for the local network to the edge switch 194.Other packets are discarded or routed to another component.

The edge switch 194 forwards the packets receive from the CMTS 199 tothe QAM modulator 189, which transmits the packets on one or morephysical (QAM-modulated RF) channels to the CPE. The IP packets aretypically transmitted on RF channels that are different that the RFchannels used for the broadcast video and audio programming (e.g.,DOCSIS QAMs), although this is not a requirement. The CPE 106 are eachconfigured to monitor the particular assigned RF channel (such as via aport or socket ID/address, or other such mechanism) for IP packetsintended for the subscriber premises/address that they serve.

“Packetized” Networks

While the foregoing network architectures described herein can (and infact do) carry packetized content (e.g., IP over MPEG for high-speeddata or Internet TV, MPEG2 packet content over QAM for MPTS, etc.), theyare often not optimized for such delivery. Hence, in accordance withanother embodiment of the present invention, a “packet optimized”delivery network is used for carriage of the packet content (e.g., IPTVcontent). FIG. 1 d illustrates one exemplary implementation of such anetwork, in the context of a 3GPP IMS (IP Multimedia Subsystem) networkwith common control plane and service delivery platform (SDP), asdescribed in U.S. Provisional Pat. Application Serial No. 61/256,903entitled “METHODS AND APPARATUS FOR PACKETIZED CONTENT DELIVERY OVER ACONTENT DELIVERY NETWORK, previously incorporated herein. As willdescribed in greater detail below, such a network provides significantenhancements in terms of common control of different services,implementation and management of content delivery sessions according tounicast or multicast models, etc.; however, it is appreciated that thevarious features of the present invention are in no way limited to suchan architecture.

Optimization Network Architecture

Referring now to FIG. 2 , one embodiment of a network architecture foruse in providing delivery platform/mode optimization is illustrated. Itwill be appreciated that the network architecture of FIGS. 2-2 b maycomprise components discussed in FIGS. 1-1 d , as well as other oradditional components not specifically disclosed therein.

As shown, the network of FIGS. 2-2 b comprises a plurality of clientdevices 206 which receive content from a broadband provisioning system(BPS) 204 of a network headend 150 via the network 101.

Generally, the BPS 204 is responsible for sending or controllingdelivery of content to the various client devices 206. It is noted thatthe client devices 206 discussed herein may include, inter alia,consumer premises devices (CPE) 106 (such as set top boxes (STBs), IPTVenabled DSTBs, media bridges (MBs), converged premises devices (CPDs),etc.), personal video recorders (PVR), digital video recorders (DVRs),network DVR, computer devices (such as personal computers (PCs) andlaptop computers), and mobile devices (including personal mobile devices(PMDs) and mobile telephones). The client devices 206 may comprise anynumber and type of apparatus for the delivery of data and/or content toa user, the foregoing being merely illustrative. Individual ones ofthese client devices 206 will be discussed in greater detail below withrespect to FIGS. 2 a-2 b and 5 .

It is further noted that throughout the present disclosure, each of theabove-described devices (including the PMD 212, PC 214, STB 222, DVR226, display device 224, CPE 106, and CPD 208 of FIGS. 1-2 b ) will becollectively referred to herein as “client devices” 206.

The network illustrated at FIG. 2 shows a BPS 204 comprising a serverentity 201, a database 250 and a monitoring and optimizing entity (OME)200. The server entity 201 of the BPS 204 in one embodiment comprises acontrol and protocol translation server. In one embodiment, the protocoltranslation is implemented in a cable modem home gateway or other suchpremises device. The cable modem home gateway translates between anMSO-specific private network-facing protocol and a CE-device facingprotocol. According to this embodiment, the MPEG video is carried inMPEG transport streams on 6 MHz QAM channels without any DOCSIS framingor IP wrappers. The modem in the home applies the IP wrapper at the timethe flow out of the modem is initiated, and includes source anddestination addresses. Tuning or other stream acquisition andtermination transactions may also be included in this translation.

The BPS 204 may be used to collectively refer to one or more of theheadend 150 entities discussed above with respect to FIGS. 1-1 d , andmay further comprise additional entities discussed herein below.However, it is appreciated that the BPS 204 may comprise any number ofdistinct or integrated entities or components, whether co-located orphysically removed from one another, that collectively responsible forproviding or otherwise controlling the delivery of data/content to theclient devices 206. For example, one or more components of the BPS 204may be disposed at various other locations (i.e., besides the headend150) as desired, consistent with the architecture implemented; e.g., atthe BSA hub in a BSA network, or at a third party location off MSOpremises.

In one embodiment, content is provided to the client devices 206directly via the server 201 of the BPS 204; e.g., as an IP packet streamor via a SIP session. In another embodiment, the BPS 204 merely directsother content delivery processes or entities to deliver content to theCPE 206.

In the illustrated embodiment, the server 201 receives content requestsfrom various ones of the client devices 206 and, only after it isdetermined that the requesting client device 206 is “entitled” toreceive the content, the server 201 provides (or causes the provisionof) the content thereto. The determination of whether a device is“entitled” to receive content is accomplished using any number ofdifferent mechanisms; see, e.g., the methods and apparatus disclosed inco-owned, co-pending U.S. Pat. Application Serial No. 12/536,724 filedon Aug. 6, 2009 and entitled “SYSTEM AND METHOD FOR MANAGINGENTITLEMENTS TO DATA OVER A NETWORK” incorporated herein by reference inits entirety. As discussed therein, a request for content is receivedfrom the client device 206 at the server entity 201 of BPS 204. Anentity at the BPS 204 (such as the OME 200, the server 201, or anotherentity) obtains information identifying the user account (such assubscriber identification number, account number, device ID such as MACaddress or IP address, etc.), and uses this information to requestentitlements from an entitlements server (not shown) located elsewhereat the headend 150. Based on the results returned from the entitlementsserver, the BPS 204 will either grant or deny the request. Theentitlements server accesses subscription information in a subscriberand device database 250 to obtain sufficient information to determinethe entitlements of the subscriber. In one implementation, the contentserver 201 or OME 200 may include the functionality of theaforementioned entitlements server therein.

In one embodiment, the server 201 of FIG. 2 comprises an applicationserver (AS) such as the Mystro™ server device of the type utilized bythe Assignee hereof as discussed in co-owned, co-pending U.S. Pat.Application Serial No. 11/263,015 filed Oct. 2, 2002 and entitled“Network based digital information and entertainment storage anddelivery system”, now published as U.S. Pat. Application Publication No.2003/0208767, which claims priority under 35 U.S.C. 119(e) the benefitof U.S. Provisional Application No. 60/377,963 filed on May 3, 2002,each of the foregoing incorporated herein by reference in its entirety.As discussed therein, the client devices 206 may communicate with the ASto receive content and/or notifications. The AS may be further adaptedto perform content processing functions such as e.g., reformattingprogram streams (transcoding, transrating, etc.), and implementing trickmode functionality.

The OME 200 may comprise one or more software applications which, interalia, monitor content requests received at the content server 201 of theBPS 202. A copy of each of the content requests received at the contentserver 201 is forwarded to the OME 200 (e.g., via inter-process message,or other communications link between the two processes). The contentrequests include information identifying the requesting device 206 (suchas IP address, MAC address, TUNER_ID, etc.). The content request mayfurther identify the subscriber account, such as account number,subscriber address, or by a user entered login password combination,etc., although it will be appreciated that only one piece of device-oraccount/subscriber-specific information is required to initiate theoptimization process. In other words, a content request may be made by asubscriber subsequent to, or in conjunction with, logging or signing in(such as via their on-screen display, to a website or other service,etc.). As will be described in greater detail below, the OME in otherembodiments may function to optimize user delivery platforms and/or modeon a “passive” or unsolicited bases (e.g., periodically, or not upon anyparticular user content request or other action).

The OME 200 determines, based on the unique identification of therequesting device 206 and/or information regarding the subscriberaccount, whether the device 206 is registered to a known user account bycomparing the identification to a database 250 of registered accountsand devices. As will be discussed below, the database 250 includes aplurality of records associating one or more devices to individual useraccounts.

Software applications running on the OME 200 (discussed below)differentiate and evaluate the various features and capabilities of thedifferent types of client devices 206 which may be used to request andreceive content for that account.

The OME 200 software application’s evaluation of the above-disclosedinformation determines (i) whether requested content may be provided tothe same user on different platforms; e.g., on one or more other clientdevices 206 associated with the user’s account, and (ii) recommendsdelivery at ones of these devices to the user. This process is generallyconducted with respect to an optimization goal or strategy (or accordingto a prescribed rule set), such as maximizing “user experience”. As usedherein, the term “user experience” generally refers without limitationto the quality and/or level of satisfaction that a user obtains fromviewing or experiencing the content. However, other optimizationgoals/rule sets may be employed, such as for example maximization ofprofit or revenue for the MSO (or advertisers or content providers),bandwidth conservation, and so forth.

In one exemplary implementation of the aforementioned “user experience”optimization, a client device 206 may be recommended to the user basedon e.g., video/audio quality (e.g., SD versus HD or up-converted SDcapability), picture size, bandwidth availability or capability (e.g.,broadband versus narrowband data delivery), and/or any other additionalcapabilities of the recommended client device 206, as will be discussedif further detail below.

The recommended devices 206 are in one embodiment presented to the userin a notification message, on-screen display window, icon, etc. whichenables the user to select one or more devices for delivery. In analternative embodiment, the notification may include all devicesirrespective of any evaluation/recommendation (or, with the recommendeddevices annotated or highlighted within the complete list). A priorityorder (e.g., best-to-worst option ranking) or similar function may alsobe provided.

In yet another embodiment, the OME 200 may comprise the functionalityand storage capability disclosed above as being attributed to thedatabase 250.

FIGS. 2 a-2 b illustrate other exemplary embodiment of networkarchitectures configured according to the present invention. The networkarchitectures in FIGS. 2 a-2 b evidence various ones of theaforementioned client devices 206 which may be used to receive content,and the various pathways for content delivery thereto (and movement ofcontent there between).

In the example illustrated in FIG. 2 a , one client device 206 is a PMD212, which receives content via either a converged premises device (CPD)208 or a media bridge 210. Other illustrated client devices include a PC214, and a IP-enabled DSTB 222 passing content to a DVR 224 and/ordisplay device 226.

The CPD 208 of FIG. 2 a may, for example, be of the type described inco-owned and co-pending U.S. Pat. Application Serial No. 11/378,129filed Mar. 16, 2006 and entitled “METHODS AND APPARATUS FOR CENTRALIZEDCONTENT AND DATA DELIVERY”, incorporated herein by reference in itsentirety. As discussed therein, the CPD 208 comprises a WLAN (e.g.,Wi-Fi) and/or PAN (e.g., Bluetooth or 802.15) wireless interface.Packetized (e.g., IP) traffic may be exchanged between the CPD 208 andone or more PMD 212 via, e.g. the WLAN/PAN interface. Hence, in oneembodiment, the PMD 212 may request content from the CPD 208, which inturn requests content from the BPS 202. The requested content may thenbe provided to the PMD 212 via the CPD 208 accompanied by the list ofother client devices 206 which are recommended by the OME 200 forreceiving the requested content. Where content is requested at a device206 other than the PMD 212, the PMD 212 may appear on a list ofrecommended devices provided to that requesting device 206.

Also illustrated at FIG. 2 a , a media bridge (MB) apparatus 210 may beutilized to provide content to the PMD 212. The MB apparatus 210 may be,for example, of the type disclosed in co-owned, co-pending U.S. Pat.Application Serial No. 12/480,597 filed Jun. 8, 2009 and entitled “MediaBridge Apparatus and Methods”, incorporated herein by reference in itsentirety. As discussed therein, the MB apparatus 210 acts as aconnection between a PMD 212 (which may include e.g., an impo ^(rt),handheld computer, smartphone, PDA, etc.) and a network. This bridgingapparatus 210 may be used, for example, to convert content stored on thePMD 212 to a format capable of being presented on a user’s set-top boxor other client device. The bridging apparatus 210 may also be utilizedfor transmitting content to the PMD 212 (such as by converting thecontent to a format capable of being stored/presented on the PMD 212),provided the user of the PMD 212 is authorized to receive the content.When the PMD 212 requests content from the network 101 via the mediabridge 210, the OME 200 may recommend alternative delivery platforms(e.g., other client devices 206) for viewing the content. Further, theOME 200 may suggest a PMD 212 for content delivery (via the MB 210) whena request for content is received from another client device 206.

In yet another embodiment, the client device 206 may comprise a personalvideo encoder (PVE) or comparable device (not shown). For example, the“Slingbox” device manufactured by Sling Media of San Mateo, CA is onesuch exemplary device which is capable of enabling a user to watch TVprogramming from various locations via an Internet-connected PC orsimilar device. The device is generally connected between thesubscriber’s cable/satellite video drop and DSTB (or other device), andhas a TV tuner inside. The user tunes to a given channel, and the PVEencodes the video streamed over the cable/satellite in Windows Media orsimilar format. The encoded content is streamed to a client applicationon a Windows XP-based or similar PC via an IP network such as theInternet, and hence the user can view the data locally (i.e., at thesame premises) or remotely so long as they have access to the IPdistribution network. This functionality can be made part of a separatephysical component, or alternatively have some or all of itsfunctionality disposed within the PVE itself. It may also be integratedwith other devices (such as connected CPE 106 or PMDs 212). It will beappreciated that the PVE may also be configured to receive other devicerecommendations and may be recommended as a platform alternative forother devices as discussed above.

In the context of the exemplary architecture of FIG. 2 a , suppose forexample that a user registers the PC 214 and the STB 222 (incommunication with the DVR 224 and display device 226) with the MSObilling system 204. The device registration is then updated to the OME200, so that the OME may build a database 250 of user accounts anddevices registered thereto (as will be discussed below with respect toFIG. 2 c ).

Suppose now that the user uses the PC 214 to request “IP TV” content(i.e., IP protocol packetized video content); this request is forwardedthrough the network 101 to the OME 200. As the requested content isprepared for transmission to the requesting device (i.e., PC 214) viathe content server 201, the OME 200 determines the subscriber accountassociated with the request and determines whether any other devices inthe subscriber’s account should be recommended as alternate deliveryplatforms. In the present example, the OME 200 will determine that theuser of the PC 214 is also associated with the IP-enabled DSTB 222(here, in communication with both a DVR 224 and display device 226). Inone embodiment, the OME 200 will provide the user of the PC 214 amessage or display notification indicating that the IPTV content isavailable for viewing at the display device 226 and/or delivery to theDVR 224. Alternatively, the notification may be reserved only for thoseinstances where an evaluation of the both the PC 214 and the DSTB 222(including display 210 and/or DVR 212 options associated therewith)reveals that, based on the capabilities of these devices, there is someadvantage in providing the content to the user on these devices 222,210, 212. For example, the OME 200 may evaluate the PC 214 (e.g., basedon device profiles maintained at the headend/OME, or via profilesobtained from the device themselves upon request) and DSTB 222 anddetermine that, based on picture and sound quality available at thedisplay device 226 and/or based on the convenience associated with theDVR 224, it is more desirable for the user to view and/or record thelive broadcast programming content at the display device 226 or DVR 224rather than (or simultaneous to) viewing at the PC 214.

Referring now to FIG. 2 b , another exemplary embodiment of networkarchitecture useful with the present invention is given. According tothis embodiment, a gateway device 220 is utilized to provide internetcontent from an internet content server 228 to one or more clientdevices 206 via the network 101. The gateway device 220 may be of thetype disclosed in co-owned and co-pending U.S. Pat. Application SerialNo. 12/582,619 entitled “Gateway Apparatus and Methods for DigitalContent Delivery in a Network” filed on Oct. 20, 2009 and incorporatedherein by reference in its entirety. As discussed therein, the gatewaydevice 220 is disposed at the headend 150 of the network 101 and isconfigured to request and receive internet content from one or more hostservers 228 via the Internet. The internet content is then processed anddelivered to one or more client devices 206. In one embodiment,processing at the gateway device 220 may include de-encapsulating thereceived internet content from a first media file container format andsubsequently re-encapsulating the internet content to a second mediafile container format which is compatible with one or more receivingdevices (such as client devices 206). According to this embodiment, thegateway device 220 may process received content automatically intovarious alternative encapsulation formats or, may encapsulate as neededto the format of the specific requesting device 206; the gateway device220 may also store the requested and re-encapsulated content to satisfyfuture user requests. It is further appreciated that the gatewayapparatus 220 may function to provide multiple alternative deliveryparadigms for the delivery of internet content to the client devices206, including delivery according to traditional broadcast mechanisms(e.g., linear delivery via downstream in-band QAM) and VOD deliverymechanisms.

As is also illustrated, a user’s PC 214 may directly access internetcontent from the internet content server 228 via the IP network. Stillfurther, a user may access internet content at a PMD 212 via a basestation 230 in communication and connected to the internet contentserver 228 via both the IP network and a cellular service provider (CSP)network and interface.

Content delivery controlled by the server 201 to one or more PMD 212 mayoccur via the methods and apparatus discussed in co-owned and co-pendingU.S. Pat. Application Serial No. 11/258,229 entitled “Method andApparatus For On-Demand Content Transmission and Control Over Networks”filed Oct. 24, 2005, incorporated herein by reference in its entirety.As discussed therein, content may be delivered on-demand to the PMD 212via a “point-to-point” approach, wherein a session is establishedbetween a content receiving entity (such as a PMD 212) and adistributing entity (e.g., server 201). In one variant, sessionestablishment and data flow control are advantageously implemented usingprotocols and bandwidth that are typically used for (i) providingon-demand services to subscribers within the cable network, and (ii)delivery and control of streaming multimedia to client mobile devices.Thus, information regarding distribution of content to various PMD 212as well as other information regarding the user’s activities withrespect to the content (such as stopping, restarting, fast forwarding,etc.) may be collected at a server entity 201 of the headend 150, viathe associated IP gateway and cellular service provider, and processedto (AMDR) messages, which are stored and/or analyzed.

Hence any of the PMD 212, PC 214 and CPD 208 of FIG. 2 b may receivealternative platform notification or recommendations, and/or be listedas recommended/available devices. Suppose for example that a userregisters each of the illustrated client devices 206, 214, 212 to theuser’s account. This information will be stored in a database 250 incommunication with the OME 200 (as will be discussed below with respectto FIG. 2 c ). When a user at the client device 206 requests contentfrom the internet content server 228 (via a the gateway apparatus 220),the OME 200 determines, based at least in part on a query of the useraccount and device database 250, that the user of the client device 206may access the same content at the user’s PC 214 and/or PMD 212. The OME200 may automatically recommend one or more of the other user devices(e.g., PC 214 and/or PMD 212) for delivery of the content, based on auser preference template or rule set (e.g., “always recommend otheravailable platforms between the times of 7:00 am and 9:00 pm”).Alternatively, the OME 200 may utilize an algorithm for determiningwhether it would be optimal to provide the content at any of the otheruser devices (e.g., PC 214 and/or PMD 212).

It should be noted that the embodiments described herein of the premisesnetwork topology shown in FIGS. 2-2 b are merely exemplary of thebroader principles of the invention; many other network configurationsand possible topologies can be utilized.

Referring now to FIG. 2 c , an exemplary user account and devicedatabase 250 is given. As shown, the database 250 contains a pluralityof records 252, 254, 256. Each user account record 252 identifies asingle user account (such as by name, address, and/or account number).

The use account records 252 are linked to one or more client devices 206which are each identified in the database 250 by a device identifier254. In one embodiment, the device identifier 254 may comprise a MACaddress, IP address, TUNER_ID, or other unique device identifier. Theuser account records 252 may further comprise information relating to alogin and password combination used by a user to verify the user asbeing associated with that account. The device identification records254 are updated via messages received from the billing system 204, oranother entity (such as an MSO server used to service subscriber loginsand account changes performed over the Internet). In this manner, onlycurrent devices and current subscription information is kept in thedatabase 250 and used for recommending delivery platforms.

Each device 206 may be optionally associated with a device descriptionfile 256. The device description file 256 describes the features andcapabilities of the devices 206 within a user’s account, such as forexample configuration information. This configuration information mightinclude e.g., (i) type and version of operating system; (ii) type andversion of codecs installed (e.g., H.264, MPEG, Real, WMP, etc.); (iii)memory and/or mass storage device capacity; (iv) display type andresolution (e.g., 1080 p); (v) communications interfaces/protocols(e.g., USB, IEEE-Std. 1394, Ethernet, UPnP, Wi-Fi, WiMAX, DOCSIS, etc.);and (vi) capabilities/function support (e.g., DRM, DNLA, DCAS). Thedevice description file 256 may be derived by the OME 200 and/or thebilling system 204 based on the device identification (see below).Alternatively, the devices 206 themselves may be configured to providecapabilities information in the form of a description file 256 ormessage (as will be discussed further below).

In another embodiment, the network architecture described in U.S. Pat.Application Serial No. 61/256,903 entitled “METHODS AND APPARATUS FORPACKETIZED CONTENT DELIVERY OVER A CONTENT DELIVERY NETWORK” previouslyincorporated herein, may be utilized in conjunction with or as analternative to the architecture discussed above with respect to FIGS.2-2 b . As discussed therein, a substantially session-based andpacketized content delivery approach (e.g., using the well knownInternet Protocol) is used, which allows for temporal, device, andlocation flexibility in the delivery of the content, andtransportability/migration of user sessions, as well as service/contentpersonalization (e.g., on a per-session/user basis) and blending(integration). This approach uses a common or unified deliveryarchitecture. In one exemplary implementation, the network is based onan IMS (IP Multimedia System) which includes SIP session protocols, aswell as a Service Delivery Platform (SDP). The IMS/SDP also uses acommon control plane and service layer, which advantageously provide ahigh level of service integration. In another implementation, thenetwork comprises both “managed” and “unmanaged” (or off-network)services, so that a network operator can utilize both its own andexternal infrastructure to provide content delivery to its subscribersin various locations and use cases. In another aspect, the inventionleverages so-called “super” headends (which provide a high degree ofcentralization of functions such as content storage, processing andback-office functions) to allow for more flexible delivery, as well asenhanced “service velocity”. A substantially network-based userinterface (UI) architecture is employed which permits the networkoperator (or a designated proxy entity) to manage and rapidlyreconfigure the UI for particular premises, subscribers (or evenparticular devices of that subscriber/premises), thereby greatly aidingpersonalization and service velocity. For example, a new serviceselected by a user can be reflected in that user’s UI simply based on adownload and installation from a network “UI” server, so that no servicecall or “truck roll” is needed. Moreover, the different UIs of thenetwork operator can be adapted to different device paradigms (e.g.,premises DSTB/HDTV monitor, PC, laptop, handheld mobile device, etc.),so that a common user and/or account “theme” and preference set ismaintained across the different devices. This UI architecture can alsoleverage next-generation content display, organization, interactivity,and recommendation engine technologies, thereby providing for a richerand more subscriber-specific (personalized) media experience.

Methodology

Referring now to FIG. 3 a , a first embodiment of the method formonitoring and optimizing content delivery in a content delivery networkis given.

Per step 302 of the method 300, content is requested by one or more CPE106. The content request is received at the server entity 201 of the BPS202 and a copy of the request is forwarded to the OME 200. The contentrequest may constitute for example an on-demand request (e.g., VoD orthe like), PPV request, IPTV delivery session establishment (e.g., viaSIP session), request for an application download (e.g., a gamingapplication from a carousel or other location), accessing and requestingdownload from an Internet website or server location, or request for anEPG or content directory.

In one embodiment, the requested content may be immediately provided tothe requesting device by the server 201, provided the requesting deviceis entitled to receive the content. For instance, information within thecontent request identifying the device (such as by IP address or MACaddress) and/or the subscriber account (such as by subscriber accountnumber or other subscriber identification) may be used to determine theentitlement of the requesting device to receive the content. The methodsand apparatus disclosed in co-owned, co-pending U.S. Pat. ApplicationSerial No. 12/536,724 filed on Aug. 6, 2009 and entitled “SYSTEM ANDMETHOD FOR MANAGING ENTITLEMENTS TO DATA OVER A NETWORK” previouslyincorporated herein, may be utilized to determine content accessentitlements. Alternatively, the requested content may only be deliveredto an entitled requesting device once the user has selected a deliveryoption from among the recommended options, as discussed below.

Per step 304, the OME 200 uses information contained in the contentrequest (information identifying the device and/or the subscriber) todetermine whether the device is registered. In order to determinewhether a device is registered, the OME 200 may compare the informationreceived to information stored in the subscriber and device database250. For example, if the request comprises information identifying thedevice (e.g., MAC address, IP address, TUNER_ID, or other unique deviceidentifier) the OME 200 will query the database 250 for that device bythe identifying information and the query returns a subscriber accountrecord 252 if the device is registered. If the request comprisesinformation identifying the subscriber account, the OME 200 may use thisinformation to determine (based on a query of the subscriber account andassociated device records 254) whether content is being requested by adevice listed to that subscriber account.

It will also be appreciated that in other embodiments, so-called “offsubscriber” devices may be made accessible to the OME. For instance, inone such variant, the subscriber may specify that certain designateddevices owned by third parties known to the subscriber can be considered“target” devices for purposes of upgrades and session migration. Forexample, an MSO subscriber might designate his girlfriend’s PC or DSTB(via, e.g., its MAC or IP address) as an approved device for contentdelivery, since he frequently watches movies or television at her house.The subscriber’s friend may or may not also be an MSO subscriber. Whereboth parties are MSO subscribers, their accounts may be linked so thatone or the other (or both) can be designated as available devices fromthe perspective of the OME. In the case where the friend is not an MSOsubscriber, delivery may necessitate carriage of the content “over thetop” of another operator’s network (e.g., a competing cable or satelliteor HFCu service provider), such as via over the Internet, non-competitorcontrolled link (e.g., WiMAX transport), or via a cooperativearrangement between the network providers. The subscriber would, in onesuch variant, log into an MSO portal or website via a user login,password, etc. to initiate a “pull” of content from an extant deliverychannel/device to the friend’s premises device. For example, the loginmay allow for a network-generated UI (akin to a website page) beinggenerated on the friend’s client device, via which the subscriber couldselect the content for delivery at the friend’s device. Login via theInternet (e.g., via a PC) may be used as well.

It is also appreciated that various embodiments of the invention may beconfigured so as to distinguish specific users versus accounts. Forexample, a given subscriber account number may be associated with thepremises of a family, yet have multiple different users (family members)associated therewith. Hence, the present invention contemplates that:(i) the account or premises may have a profile or preference setassociated with it as a whole (e.g., one preference set for all familymembers, and a listing of all family member devices); (ii) thatindividual users may have their own preference sets and device listings,which may or may not overlap with other members (e.g., two differentfamily members might list the living room DSTB/DVR as “their” device);and (iii) combinations of (i) and (ii) (e.g., such as where each memberhas a separate preference set and device list, but there is a default“family” profile). Hence, content may move or be “upgraded” forindividual users largely independent of other users within the samesubscriber account under one embodiment of the invention (except e.g.,where a “collision” or resource contention would occur, such as wheretwo family members are trying to move different content to the samedevice at the same time). As used herein, the term “user” therefore canrefer to one user or multiple aggregated users.

If the requesting device and/or subscriber account identificationinformation does not match an entry in the database, the device has notbeen registered. A device must be registered before content may beprovided thereto. Hence, per step 306, the device is registered byproviding information identifying the device and/or subscriber to theOME 200. At step 308, the OME 200 associates the device to a subscriberaccount. In one embodiment, this occurs by automatically querying thebilling systems via the devices MAC address to develop a defaultprofile. In another embodiment, the device may be configured toautomatically provide device identification and/or subscriber accountinformation to the BPS 202. The server maintains historical heuristicdata which “mines” or determines device content usage patterns in orderto determine a more precise custom profile against client futurebehavior and usage, in one embodiment. Alternatively, a user may entersome or all of the aforementioned information at a user interface (e.g.,web portal run by the MSO), such as by entry of a login and passwordduring a registration process to create a default profile. The OME 200may verify the entered information at the billing system 204. The OME200 may also request additional information at the billing system 204.For example, if the device only provides device identificationinformation, the OME 200 may query the billing system 204 for thesubscriber account to be associated therewith (step 308). Per step 310,the device and associated subscriber account information are reported toand updated in the database 250 records 252, 254.

The OME 200 may also periodically request updates from the billingsystem 204 or other cognizant entity to update records in the subscriberand device database 250. In this manner, only the most recently updatedlists of devices 206 are used for providing delivery platformnotifications (as will be discussed below).

If the requesting device identification matches an entry in thedatabase, the device is determined to be registered and, at step 312,the subscriber account and device database 250 is evaluated to determinewhether there are additional delivery platforms (e.g., other devices 206registered to the user’s account) available for the provision of therequested content. To this end, the OME 200 may run one or more computerapplications for evaluating the available devices 206 listed in thedatabase as being part of the user’s account. As will be discussed ingreater detail below, the aforementioned computer applications runningon the OME 200 may also be utilized to evaluate whether one or more“better” or more appropriate platforms exist, such as by taking intoconsideration various of the aforementioned configuration factors,available bandwidth, and/or bandwidth requirements for each platform.Alternatively (or in conjunction), the evaluation may be based at leastin part on the user (e.g., via user-specified rules or preferences).

The present invention recognizes the fact that “best” or “better” may behighly account or user-specific terms, and predicated on an analysis orpreference from the user which at all times may not seem rational. Forexample, a user may specify a preference to watch a smaller/lowerresolution monitor, or PC monitor, versus their best quality platform,simply because they enjoy the location of the smaller/less capablemonitor better, have other functions they can be performing whilewatching programs (e.g., it’s in the garage, kitchen, laundry room, outby the pool, etc.). As previously noted, templates or rules can also beapplied, such that certain preferences are only in effect in certainscenarios, under certain preconditions, at certain times of day, etc.Hence, user-based preferences or inputs (which may also includepassively obtained data, such as history of user usage of certaindevices, watching certain modes of delivery (e.g., VoD HD versus SD PPV,etc.) may also be used as a component in the “recommendation engine” ofthe present invention.

Moreover, QoS-based considerations can be used in the evaluation ofdelivery modes/platforms according to the present invention. Forinstance, a given delivery channel such as IP-based MPEG-4 encodedcontent may be delivered over an in-band or DOCSIS QAM in a cable orsatellite network, each of which carries with it inherent QoS and FECrequirements. However, the same content may also be streamed over anon-QoS channel (e.g., via the Internet, which has no such QoS/FECrequirements, thereby potentially impacting user experience). Certainusers may be amenable to non-QoS delivery in exchange for example timeand/or place utility (e.g., so they can watch it on the platform oftheir choice when they want to watch it).

Cost is yet another factor that may be considered in evaluation ofdelivery mode/platform. For example, a user may be amenable to watchinga lower-quality free version of a given content element or programversus a high-quality “pay” version. This may also be viewed from thenetwork operator’s perspective (e.g., the network operator may alwaysopt to deliver the higher-quality “pay” version so as to increaserevenue or profit, or seek to deliver the version or via the mode withthe least incremental cost (e.g., that is locally cached, or does notuse up bandwidth that could be applied to a higher-revenue use).

It is also noted that in certain embodiments of the invention, availablealternative delivery platforms may be specified or selected based on theavailability of the requested content in an encoded format that issuitable for the platform. For instance, if the content is onlyavailable in MPEG2 format, a prospective alternate client device havingonly an H.264 decoder would not be a suitable alternative, and hencewould be eliminated from consideration (despite the fact that it maysatisfy other optimization goals such as providing better userexperience, use less bandwidth (H.264 consumes roughly half thebandwidth of MPEG2), etc.

Accordingly, the present invention further contemplates distinguishing“required” factors from “elective” factors. Required factors might forexample include suitable codec support, suitable container decodingsupport (e.g., MP4 container), suitable transport, suitable QoS support(if required), and so forth. Elective factors might include HD orupconversion capability, QoS support (if QoS is not required), HD audiocapability, display monitor size/resolution, “surround sound”, recordingcapability, and so forth. Hence, potential alternative devices can beeffectively screened in one embodiment of the invention by firstevaluating all of the required factors (for a requested content elementand designated delivery mode) against the available devices, andfiltering those which do not meet all requirements.

Per step 314, a notification is sent to the user indicating thealternative delivery platforms (e.g., other user devices 206 associatedwith the user’s account), if any, and enabling the user to selectindividual ones of these platforms for the delivery of the requestedcontent. The user is notified in any number of ways; for example, thenotification may be transmitted only to the device 206 on which the useris currently receiving content or has requested content. Alternatively,the notification may be transmitted to all of the client devices 206associated with the subscriber’s account. The notification mayintentionally list the recommended devices 206 according to a hierarchybased on the suitability of the device 206 for delivery of the requestedcontent.

The notification in one variant comprises an interactive applicationwhich enables the user to select one or more of the given platforms forcontent delivery. In response to the notification, the user may selectto view the content on the requesting client device 206, continueviewing the content on the current client device 206, or the user mayselect an alternate client device 206 for simultaneous or alternativecontent provision. In other words, the user may: (i) select to continueor to begin viewing the content on the requesting client device, (ii)may also have the content sent to one or more second client devices, or(iii) or may select to only receive the content on the second clientdevice(s).

In another embodiment, all devices 206 of a given user account arepresented as delivery options regardless of their desirability forproviding the content. In other words, the user is able to choose, fromamong all the devices 206 associated with the user account, the devices206 on which to receive the requested content. These devices can alsooptionally be ranked; e.g., according to the aforementionedrecommendation hierarchy based on the foregoing evaluation, so as toapprise the user of which are the best choices (while also allowing themto see all options). Moreover, those that are incompatible or ineligiblefor delivery can be so noted (e.g., with an icon, different coloration,etc.).

Once the user’s selection(s) are received (step 314), the requestedcontent may be provided to the selected platform(s) at step 316.

The notification may, in another embodiment, be of the type described inco-owned, co-pending U.S. Pat. Application Serial No. 11/706,620 filedon Feb. 14, 2007 and entitled “Methods and Apparatus for ContentDelivery Notification and Management” which is incorporated herein byreference in its entirety. As discussed therein, the notification mayoffer the user one or more choices, including the choice to eithercancel the request or to accept delayed delivery of the requestedcontent on one or more of the available client devices 206. As alsodiscussed therein, if content is requested by the subscriber during atime (or for a time) where the network capacity or bandwidth availablefor delivery of that content is limited, the notification may alert thesubscriber of a potential unavailability of requested content.Similarly, the notification can be made to be dependent on the status ofthe “target” device(s). For instance, if the user selects a device whichis “available” per the billing system, but may not be powered on orconnected to the network (and hence not available to receive thedata/session associated with the content delivery), then the user of therequesting device will receive notification to this effect, and eitherallow them to wait or retry after a timeout period, or select anotherdevice.

The notification may further provide the subscriber with a projecteddelivery or availability time for the requested content (either at therequesting client device 206, or at another available device 206). Thenotification may also allow the subscriber to specify a date and/or timeof delivery, such as one convenient to them at any one of the availableclient devices 206 (e.g., “ten minutes from now”). Still further, thenotification may provide the subscriber with a “content/device ready”notification when (i) the content is actually ready for delivery; and/or(ii) the device is ready to accept or display it. The notification mayalso automatically program or operate the requesting client device 206or other available client device 206 based on projected or actualdelivery information.

Suppose for example, User A registers a PC, a mobile device, a digitalset top box (DSTB), and a DVR to the user’s account. This information isstored at the database 250, and when User A requests broadcast contenton his/her PC (step 302), the OME 200 uses the database 250 to determinethat the same content may also be viewed by User A on the otherregistered devices. The OME 200 evaluates the other features andcapabilities of the other registered devices 206 (step 312). Supposethat the evaluation results in the OME 200 determining that therequested broadcast content is better delivered to User A on either hisDSTB or recorded on his DVR. Thus, the OME 200 generates and transmits amessage to User A informing the user of the “better” delivery options(step 314). User A may then select to receive the content as requested(e.g., at the requesting PC) or may select delivery at one or more ofthe recommended devices (step 316). For example, User A’s selection mayresult in the requested content being simultaneously or alternativelyrecorded at User A’s registered DVR, and/or may result in a forced“channel” change of User A’s registered DSTB (e.g., to a QAM or packetstreaming session).

The present invention may be further configured to provide selection ofa delivery platform without user intervention (e.g. automatically). Forexample, the evaluation may give a clearly “best” device 206 fordelivery, the delivery may be effected to that device, and thenotification merely indicates to the user that the content will bedelivered to the “best” device. This can also be subject to userconfirmation (e.g., “OK to switch?”), and/or user-based preferences orrules sets (e.g., “never switch from 1080p plasma display to PC”).

In another example, a master scheduler may be used. The master schedulermay enable the user to select one or more of the CPE 106 associated withthe user’s subscriber account for delivery of the requested content. Themaster scheduler, in one instance, may deny programming to client basedon profiles, during certain periods, based on the programming contentitself, etc. For example, adult programming may be denied when it isknown that the client device is associated to a minor and/or duringcertain periods. In another instance, the master scheduler can initiatea push of content to certain devices that have storage capabilities. Thecontent push may be based on the content itself, the time of viewing,etc. In another instance, the master schedule is configured to movecontent from devices around the networks based on specific criteria,local storage maximization, device usage, and/or period usage. Forexample, the master schedule may assist a user in moving requestedcontent to their vacation home during a vacation, or routing phonecalls.

It will also be appreciated that the logic of the method of FIG. 3 a maybe modified such that it is event-driven; e.g., the powering-up, networkaccess negotiation, and/or logging on of a user device/user may triggerone or more of the foregoing processes. For instance, in one suchvariant, the startup of a device and establishment of communication withthe content delivery network (e.g., via an upstream “startup” message orrequest for network address, etc.) is used to trigger the OME toevaluate the newly initiated device relative to the extant deliveryplatform. If the newly initiated device is ranked higher or moreoptimized for delivery of the content, then a notification will begenerated and sent to the user on the current recipient device,apprising them of the prospective “upgrade”.

Alternatively, a complete evaluation (such as that described in FIG. 3 a, where all associated devices within the subscriber/user account areevaluated) may be performed.

Referring now to FIG. 3 b , a second embodiment of the method formonitoring and optimizing content delivery in a content delivery networkis given.

As shown in FIG. 3 b , the method 330 is generally institutedperiodically or anecdotally (e.g., upon the occurrence of a prescribedevent or sequence of events). In one variant, the OME 200 periodicallyqueries or obtains status on the devices connected to and operable atthe premises, and updates an “availability” list based on this statusinformation. For instance, where a PMD is not wirelessly coupled (viae.g., Wi-Fi) to a premises CPD or network, it is considered“inaccessible” even though it may be actively in use. Similarly, if aDSTB does not display a “heartbeat”, or is powered off, it may beconsidered unavailable. Likewise, the failure to generate an appropriatevoltage or signal on a pin of a DisplayPort, IEEE-Std. 1394, RJ-45/LAN,or USB interface may indicate a lack of connection.

To this end, a distributed application (DA) with a “server” portion and“client” portion can be utilized. For example, the client portion may bedisposed on a network gateway or CPD at the premises, and run so as toperiodically poll or determine status of the various registered deviceson the premises network. This information is used by the client portionto either (i) generate notifications or recommendations locally at thepremises; or (ii) generate a message or signaling upstream to the OMEserver portion, so that the latter can generate notifications orrecommendations.

At step 332 of the method 330, the OME (or its proxy) selects a firstdevice (“n”) from a listing of available devices for that premises. Thislisting may be obtained locally (e.g., at the premises itself, such asone stored on a gateway, CPD, PC, or other device), or via theaforementioned subscriber database.

At step 334, the status of the selected device as a current deliveryplatform is determined. For instance, in one variant, the OME 200determines whether content is actively being delivered to that devicefrom the network (e.g., via in-band QAM, IP session, WiMAX transport,etc.). The control and protocol translation server may, in oneembodiment be configured to store information relating to what thecontent currently being sent to any subscriber premises and/or devicesassociated therewith. The server generates this information based on itsrole in receiving all of the content request messaging, whether on oroff the network, as programmed in the client device or software. Theserver may then use this information to manage the device states.

In another variant, each of the user’s devices can be equipped with aclient portion or application which allows the user to “pull” contentdelivery to that platform.

As previously noted, devices outside the user’s premises may also beincluded within a device listing associated with a given account. Forexample if User A frequently visits their neighbors down the street (whoare not MSO subscribers) and watches movies there, such as everySaturday night, they could add the MAC address or other identifying dataassociated with their neighbor’s CPE (e.g., DSTB) to their accountprofile. When they arrive at their neighbor’s house, the subscribercould log in (i.e., user-based login/password/security challenge, etc.)via their neighbor’s IP-enabled CPE, and then request content from thatCPE (e.g., via an IP-based delivery transport such as the Internet,which may even include for example a DOCSIS delivery over another MSO’snetwork).

If the neighbors are also MSO subscribers, but perhaps may not have thesame privileges or features (e.g., HBO subscription) at their house, thesame logic may be applied, yet delivery of the HBO content may occur,yet via in-band QAM, WiMAX transport, or other MSO-operated deliveryinfrastructure.

These delivery use cases illustrate the “TV anywhere” concept affordedto MSO subscribers under one embodiment of the present invention.

If the selected device is currently being used to receive content fromthe network (step 336), this device is marked as “current”, and the nextdevice in the listing selected per step 338. If not, then the selecteddevice is evaluated by the OME to determine its capabilities per step340. The evaluation may be as simple as determining whether the selecteddevice is capable of receiving the requested content (e.g., it may berendered at a resolution incompatible with the selected device, may beencoded using an incompatible codec or container format, may requiremore delivery bandwidth than the transport can sustain, may not meet QoSrequirements, etc.). However, more sophisticated evaluations may also beconducted (e.g., to characterize the device in various differentaspects).

At step 342, it is determined whether the selected device that wasevaluated at step 340 was the last device on the listing (i.e., whetherall devices associated with the premises or account have beenevaluated). If so, then the results of the evaluations, and anytemplates or user-specified rules sets, are processed by the OME 200 todetermine a recommendation/hierarchy per step 344. If not, theadditional remaining devices in the listing are processed as above.

In another embodiment of the invention, a user-assigned heuristicregarding the desirability of each device in their listing can be usedas the basis of ranking or selection. For instance, a user is on onevariant presented with a GUI listing the several devices available atthe premises (e.g., HDTV monitor (54 inch), HDTV monitor (32 inch), PC,laptop, and smartphone). The user may specify that it is always mostdesirable to prioritize the 32-inch monitor, since that is where theuser watches most of his/her programs (even though the 54-inch may givea better “user experience” in terms of video and audio quality).However, when the user is not at their premises, the primary desiredmode of delivery might be listed as the laptop computer (followed by thesmartphone).

Audio aspects can also be considered as part of the evaluation/ranking.For instance, in the context of the foregoing example, one of the HDTVmonitors may also include “surround sound” or similar, which greatlyenhances the audio aspects of the content presentation. These may becombined with (e.g., according to a weighting function) video aspects of“user experience” as part of the evaluation process.

Session Transfer

Referring now to FIG. 4 , one embodiment of a generalized method formanaging and transferring content delivery sessions is disclosed. Asnoted elsewhere herein, one operational scenario in which the presentinvention may be employed comprises a user having content delivered to afirst client device (e.g., DSTB), and then wanting to transfer thatcontent “mid stream” (and in some cases without significant loss ordiscontinuity) to another client device, such as pursuant to anotification/recommendation from the OME. One approach for effectingthis transfer would be to simply have the user power-on the target(transferee) device, and then tune or switch that device to theappropriate delivery channel, and then subsequently switch off thetransferor (original) device. However, this approach is far fromelegant, and does not optimize user experience in that the foregoingswitch may take time and result in loss of content (especially where thecontent being delivered is linear or broadcast).

Accordingly, the improved methods and apparatus of the present inventionseek to provide a substantially seamless mechanism for such transfers.In one embodiment, an extant session (e.g., SIP session between acontent delivery server and the first client device (transferor)) ismaintained and modified to add the transferee device, with subsequentremoval of the transferor device from the session. As describedelsewhere herein, “state” information may optionally be utilizedconsistent with this approach in order to allow for transfer withoutsignificant discontinuity, even where the transferee device is not yetpowered up or available.

As shown in FIG. 4 , the first step of the method 400 comprisesestablishing a communication session between a content source and afirst recipient device (transferor) using a session-based protocoladapted for use on a packet-switched network, e.g., SIP (step 402).Content is then transferred to the first recipient device within thesession, such as via an RTP stream per step 404. Next, a communicationsession is established between said content source and a secondrecipient device (e.g., transferee) per step 406, and delivery of thecontent to the second recipient device is commenced per step 408. Thismay be pursuant for example to a notification/recommendation generatedby the OME as described elsewhere herein; e.g., that the transfereedevice is somehow “better” or more optimal for delivery of content atthat point in time.

Delivery of content to the first device may then be ceased as desired(step 410).

It is noted that in step 406, the session established between thecontent source and the second recipient device may be the same or adifferent session than that established in step 402 with the firstdevice; e.g., a SIP session can advantageously have multipleparticipants within the same “session” (e.g., via conferencing), andhence deliver a given content stream to multiple endpoints, althoughsuch use of a unified session is by no means a requirement of theinvention.

For instance, in one implementation of the method 400, the contentsource comprises an IP TV (Internet Protocol television) server disposedwithin a content delivery network (e.g., a satellite or Hybrid Fibercoaxial (HFC) cable television network, and the packetized content isdelivered according to a unicast session via one or more DOCSIS or otherQAM channels). In one embodiment, live content is also delivered via amulticast delivery system. If the consuming device capabilities do notalign, more than one multicast may be initiated. In some instances, thishas the desired effect of improving the efficiency of the deliverymechanism when more than one customer requests a stream in the sameservice group, and entails little penalty in terms of bandwidth evenwhen only one device is consuming the stream.

The aforementioned method may also be performed automatically (i.e.,without substantial user intervention) if desired. For instance, once anotification of a prospective “upgrade” is sent to the user, if the useropts to accept the upgrade, the foregoing transfer can be automaticallyinvoked without further user action.

FIG. 4 a illustrates one implementation of the generalized method ofFIG. 4 , wherein a SIP session and RTP stream (with QoS) are used inconjunction with an IPTV server (e.g., MPEG2 or MPEG4 encoded contentpacketized via the IP protocol and delivered via TCP transport over aPHY such as MPEG2 transport stream, etc.). The native SIP methods (e.g.,INVITE, etc.) are used to establish what amounts to an RTP streammulticast to the two delivery devices (i.e., transferor and transferee)in parallel for at least a period of time, and then delivery to thefirst device ceased, if/when desired.

Moreover, various techniques can be invoked and used within theforegoing methods so as to avoid loss of “state” of the deliveredcontent. For example, where the content delivery mechanism within thefirst session is non-linear (e.g., VoD, nPVR, or similar), a simplecommand or signal to the content delivery server to pause the stream canbe used, thereby preventing any loss of content from the user’sperspective. In cases of linear content delivery (e.g., live broadcast),a network- or premises-based recording function can be invoked, such aswhere a network DVR or premises DVR function is messaged to startrecording the stream from a prescribed timing coordinate, packet ID, orcue until the second session is established or the user affirmativelyallows content delivery via the second session (e.g., selects an “OK”function on the second device, thereby allowing for continued contentdelivery).

In yet another implementation, the linear packet stream can simply bebuffered (e.g., at the server, such as in a FIFO buffer sizedappropriately for a suitable transition time), and the buffer contentsread out when the second session has been established and the user hasOK’d further delivery.

It is appreciated that the foregoing functionality may be implementedaccording to any number of different network architectures. For examplethe well known IMS (IP Multimedia Subsystem) associated with 3GPP andother relevant standards can be used as a basis for the foregoing SIPsessions and functions. IMS is particularly designed with a commoncontrol plane architecture which advantageously facilitates “blending”of control functions of services and applications, such as is describedin U.S. Provisional Pat. Application Serial No. 61/256,903 entitled“METHODS AND APPARATUS FOR PACKETIZED CONTENT DELIVERY OVER A CONTENTDELIVERY NETWORK, previously incorporated herein. This technology isparticularly useful in cross-network (e.g., off-net to on-net, and viceversa) transfers of sessions such as those contemplated by the presentinvention, since the common control plane architecture allows forhandover of the session across network boundaries. For example, in onesuch scenario, a user may wish to transfer an extant “broadcast” sessiondelivered over say a cable or satellite or HFCu network to a cellular,WiMAX, or FLO (Forward Link Only)-enabled handset or mobile device, suchas when the user is leaving their premises but wishes to keep watching agiven program. By instantiating delivery of the broadcast/linear oversay a SIP session to the premises device, and then transferring thesession to the handset (and hence delivering the packetized media streamover the IMS infrastructure off-net), the user can experience a seamlesshandoff to the handset, which will then receive the packet stream viathe designated wireless infrastructure (e.g., UMTS/3G, WiMAX, FLO,etc.), yet which is still originated from the MSO network sources. Inthis fashion, MSO-derived content (which may come from off-net sourcesitself, such as the Internet) can be delivered to MSO subscribers bothon-net and off-net, and switching back and forth is easily accomplished.

Optimization and Monitoring Entity

Referring to FIG. 5 , an exemplary embodiment of the OME apparatus 200is illustrated. As shown, the OME 200 generally comprises a networkinterface 504, a processor 506 having associated storage 516, and aplurality of back end interfaces 508. Other components which may beutilized within the OME 200 include amplifiers, board level electroniccomponents, as well as media processors and other specialized SoC orASIC devices (not shown). Support for various processing layers andprotocols (e.g., 802.3, DOCSIS MAC, OOB channels, DHCP, SNMP,H.323/RTP/RTCP, VoIP, SIP, etc.) may also be provided as required, suchas in support of data and “rules” interchange between the OME 200 andthe client devices 206.

The network interface 504 enables direct or indirect communicationbetween the OME 200 and various entities of the network 101, such ase.g., the client devices 206. It is noted that the network interface 504may comprise a plurality of interfaces for use with other networkapparatus such as RF combiners, IP routers and other packet networkdevices, network management and provisioning systems, local PCs, etc.The interface 504 may be e.g., an IEEE-1394 interface, a USB interface,a LAN interface, an ASI/GBE interface, wireless (e.g., WiMAX) etc.

The back end interfaces 508 comprise a plurality of interfaces (e.g.,IEEE-1394, USB, LAN/WAN, Wireless, etc.) which facilitate communicationbetween the OME 200 and other network devices, such as those in the BPS202 (e.g., the server 201 and database 205). The back end interfaces 508may also facilitate communication with other devices (not shown) in theBPS 202 or elsewhere in the network 101 as needed, such as othermanagement processes.

The processor 506 is configured to run a monitoring application 510, anevaluation application 512 and a notification application 514 thereon.In the illustrated embodiment, each of these applications 510, 512, 514work in conjunction with one another and with the BPS 202 entities todetermine, evaluate, and provide notification of one or more alternativecontent delivery platforms, each of the applications 510, 512, 514 willbe described in turn herein below.

The monitoring application 510 running on the OME 200 monitors thedevices 206 receiving content by communicating with the server 201 toreceive copies of content requests which were sent to the server 201from the client devices 206. In other words, as a client device 206requests content from the server 201, the request is copied andforwarded to the OME 200. Other schemes may be used as well, however,such as where the content requests are routed through the OME first andforwarded to the server, delivered in parallel, or one entity signalsthe other without copying or forwarding the request (which may includeextraction of relevant information, and creation of a separate messagein the appropriate format for inter-process communication between theentities).

The monitoring application 510 uses information in the content requeststo identify the client device 206 requesting content and to identify thesubscriber account associated with the client device 206. For example,the content requests may contain a unique device identifier (such ase.g., IP address, MAC address, digital signature (e.g., hash or residue,etc.); the content requests may further contain information identifyinga subscriber account (such as e.g., subscriber account number,subscriber address, login and password combination, secret image orchallenge question information, etc.).

In the event that only the device 206 identification is provided in thecontent request, the monitoring application 510 will determine thesubscriber account with which the device 206 is associated (if any). Inone embodiment, the monitoring application 510 will do so by queryingthe device description records 254 stored at the database 250 to find asubscriber account association (e.g., to find the subscriber accountrecord 252 linked thereto). In another embodiment, the monitoringapplication 510 may query the billing system 204 to find an associationof the given device 206 to a particular subscriber account.

Once the monitoring application 510 identifies the device 206 and itsassociated subscriber account, the application passes this informationto either the notification application 514, or the evaluationapplication 512, or both. If the information is passed directly to thenotification application 514, the application 514 simply generatesnotices to the subscriber indicating all of the devices 206 which areavailable. If the information is passed to the evaluation application512, the application 512 determines whether any of the available devices206 is a “better” or more appropriate platform for the delivery of therequested content, and makes a recommendation. The recommendation isthen forwarded to the notification application 514 so that a notice maybe sent to the user reflecting the information generated by theevaluation application 512 (e.g., a hierarchical ranking of options,deletion of those not meeting a specified criterion or level of service“quality”, etc.).

The evaluation application 512 running on the processor 506 of the OME200 comprises one or more computer programs adapted to evaluate contentdelivery modes/platforms, once it is determined one or more clientdevices 206 are available for delivery of the requested content (e.g.,are registered to the same account as the requesting device 206)Aspreviously discussed, the application 512 may also include a“recommendation engine” which recommends one or more for alternativeand/or additional delivery of the requested content. In other words, inthe exemplary embodiment, the monitoring application 510 determines allof the devices 206 in the subscriber’s account, and forwards thisinformation to the evaluation application 512. The evaluationapplication 512 evaluates each of the available devices based on one ormore criteria, and provides a list or other means of indicating one ormore delivery platforms which are deemed to be appropriate for thedelivery of the requested content (or more appropriate than therequesting device 206). It is noted, however, that in alternateembodiments, the monitoring application 510 may pre-process or filterthe list of “available” devices before sending this information to theevaluation application, such as where the monitoring applicationdetermines the state of each device associated with a user (or account),and filters them based on lack of accessibility. Devices may also bearranged by the monitoring application by tier or classification; e.g.,currently powered-on versus powered-down devices, HD-capable versusnon-HD capable devices, fixed versus mobile devices, etc. This may beaccomplished based on configuration information contained within thesubscriber/device database, via a query to each device (or monitoringsome aspect of device operation, such as a periodic heartbeat), query tothe user for device status, or any combination of the foregoing, asdescribed in greater detail subsequently herein.

As noted above, the appropriateness of a content delivery device 206 maybe determined based on one or more of a variety of criteria, includingwithout limitation: (i) device availability/current status; (ii)capabilities (e.g., hardware/software configuration); (iii) costimplications to the user; (iv) cost/revenue implications to the networkoperator; (iv) picture/audio quality and “user experience”; (v) networkparameters/limitations (e.g., bandwidth, need to instantiate a newsession or QAM for delivery, etc.); and/or (vi) user preferences and/or“templates” provided by the user. For example, the evaluationapplication 512 may be configured to evaluate each of the devices basedon bandwidth requirements/availability. In one embodiment, the apparatusand methods disclosed in co-owned, co-pending U.S. Pat. ApplicationSerial No. 11/243,720 filed on Oct. 4, 2005 and entitled“Self-Monitoring and Optimizing Network Apparatus and Methods”,incorporated herein by reference in its entirety, may be used by theevaluation application 512 to recommend devices 206 for optimizedcontent delivery. As discussed therein, the evaluation application 512may employ a substantially automated and anticipatory mechanism wherebya content delivery network, such as a broadcast switched architecture(BSA) network, can effectively “self-monitor” and optimize its bandwidthallocation based on, inter alia, data received from the receivers (e.g.,DSTBs) within its service area, or from the network as a whole. Theevaluation application 512 analyzes information gathered from thedevices 206 (as well as optionally other information relating to, e.g.,the network itself or other historical periods) to determine theexpected statistical variations of the system as a function of time andvarious events (e.g., holidays), and the expected statistical viewingbehavior of known future details of the offered content, in effectallowing it to predict subscriber behavior and make adjustments to theoperational parameters of the network based on these predictions.

As another example, the methods and apparatus of co-owned co-pendingU.S. Pat. Application Serial No. 11/881,034 filed on Jul. 24, 2007 andentitled “Methods and Apparatus for Format Selection for NetworkOptimization”, incorporated herein by reference in its entirety, may beutilized to determine which devices of a subscriber’s available deviceswould be best suited for providing optimized content delivery.Accordingly, the evaluation application 512 may be configured toevaluate and recommend devices 206 for content delivery which minimizebandwidth consumption while also maximizing subscriber satisfaction andservice level (e.g., video and/or audio quality).

The evaluation application 512 may also take into account what is knownabout the devices 206 (e.g., HD capabilities, MPEG2 or MPEG4 decodingcapabilities, etc.) to determine which devices should be recommended (orhow the multiple devices should be ranked). For example, if it is knownthat a group of user devices 206 in a service area are HD-capable, thenthe evaluation application 512 may recommend a user utilize the ones ofthe user’s devices 206 which are HD capable, thus enabling these devices206 to tune to any available HD versions of programs to reduce theinstances of duplicate programming, and to satisfy SD programmingrequests using HD programming. Conversely, in times of constrainedbandwidth, the evaluation application 512 may recommend only SD capabledevices (and/or not recommend HD devices) 206 so that an SD version of aprogram (or a lower bitrate stream of the HD program) may be delivered,including during instances where an HD program is requested. Theevaluation application 512 may further take into account whetherparticular ones of the user’s available devices 206 have up-conversioncapability, in which the user may still advantageously experiencesubstantially “HD-quality” video, even though the device 206 input hasbeen switched to SD, and may recommend these devices in instances ofconstrained bandwidth.

The evaluation application 512 may also evaluate the devices 206identified by the monitoring application 510 as being within thesubscriber’s account, and make recommendations based at least in part onwhat is known about the user. For example, the evaluation application512 may be configured to record information regarding the viewing habitsof the subscriber with respect to the one or more devices 206 heldwithin the subscriber’s account, and utilize this information torecommend (based on the type of content requested and/or the requestingdevice 206), other platforms for delivery of the content, and/or othercontent for delivery on the requesting device 206.

Suppose for example, that previous (historical) viewing patterns forUser A indicate that User A enjoys viewing broadcast or “linear” contentthe vast majority of the time on his in-home DSTB. Accordingly, when arequest is received from User A from a mobile device for broadcastcontent, the evaluation application 512 may utilize the historicalinformation to determine that it is possible that User A would prefer toview the content on his DSTB (or record the content on his premises DVRfor later viewing), and may therefore recommend this device to User A.In addition, the evaluation application 512 may, based on theaforementioned viewing patterns, recommend content similar to thecontent being requested (and which is in a compatible format) forviewing by User A on the mobile device.

The aforementioned historical data collection and storage may beprovided using e.g., the methods and apparatus disclosed in co-owned,co-pending U.S. Pat. Application Serial No. 11/243,720 filed on Oct. 4,2005 and entitled “Self-Monitoring and Optimizing Network Apparatus andMethods”, previously incorporated herein.

The aforementioned embodiment of the evaluation application 512, whereinit recommends alternative delivery platforms (e.g., alternate devices206 associated with the user’s account) based at least in part on thecapabilities of the various devices 206 available to the user, may beconfigured to obtain the device capabilities via a variety ofmechanisms. For instance, a device profile defining the various featuresand capabilities (including content decoding capabilities, securityfeatures, etc.) of the devices 206 may be transmitted to the network(e.g., the billing system 204, the OME 200, or a storage entity incommunication with either located at the BPS 202 or elsewhere at theheadend 150) from each client device 206. These device profiles may bepart of a content request (e.g. as part of a message payload, metadata,etc.), or sent as a separate communication, and may be of a standardizedformat as well, thereby facilitating ingestion into the network. Theseprofiles may be periodically or anecdotally updated as well, such as viaa “push” from the CPE to the network (e.g., upon startup), or a “pull”from the network (e.g., a request sent from the OME or other networkentity to the CPE when an update is required). In one embodiment, themethods and apparatus disclosed in co-owned, co-pending U.S. Pat.Application Serial No. 11/904,408 filed on Sep. 26, 2007 and entitled“Methods and Apparatus for Device Capabilities Discovery and UtilizationWithin a Content delivery Network”, which is incorporated herein byreference in its entirety, are used. This disclosure describes interalia apparatus and methods for determining and selecting digital codingand/or decoding technology, delivery bitrates, and resolution parametersfor programming and data delivery over, e.g., a content deliverynetwork. Hardware and software functions/modules of the differentdevices 206 on the network contain various capabilities and options,including conditional access capabilities, video coding or compressioncapabilities, encryption schema, and network interfaces. These aretransmitted to a headend entity (e.g., the OME 200) in the form of acapabilities profile for analysis. The headend entity determines the oneor more capabilities possessed by client devices 206, and evaluates oneor more program or content choices for possible delivery to each of thedevices 206 based on its profile. In the context of the presentinvention, the evaluation application 512 may evaluate the devicecapabilities discussed above when making device rankings orrecommendations. The evaluation application 512 may further take intoconsideration network and/or device operational considerations, such asconservation of downstream bandwidth, device uprating capability, clientdevice power consumption, and the like according to this embodiment, asdiscussed elsewhere herein.

In another embodiment, the client device 206 capabilities may be derivedexclusively from the OME 200, billing system 204, or other headendentity. For example, when a user registers a device 206 to the billingsystem 204 (and information regarding the device 206 is stored at thesubscriber device database 250), the billing system 204 and/or OME 200may utilize information identifying the device (such as the IP address,MAC address, etc.) to generate a device description record 256 (as shownin FIG. 2 c ) which is associated to the particular device descriptionrecord 254 in the database 250. In other words, the OME 200 and/orbilling system 204 (or other entity) at the time a device 206 isregistered may generate capabilities information regarding the device(based on information obtained during registration) in order to generatea device description record 256.

The evaluation application 512, in another embodiment, may utilize theMAC address associated with the requesting devices 206 and received bythe OME 200 as a part of a content request to determine recommendations.The OME 200, upon receiving the MAC address, may identify a portion ofthe address (such as e.g., the organizationally unique identifier orOUI) as indicative of the type of device requesting access to content.The OME 200 may utilize this information to determine the precise one ofa subscriber’s devices which is requesting content, and recommend analternative delivery platform based thereon (e.g., based on anotherdevice with similar capabilities/configuration profile). For example,suppose the OUI of the MAC address of the requesting device indicatesthat the device is manufactured by Scientific Atlanta, and also that asubscriber has registered a Dell PC, a Motorola MR-DVR, an Apple laptopcomputer, and a Scientific Atlanta STB within their MSO account. The OME200 is configured to deduce that the requesting device is the STB basedon the MAC address OUI (indicating Scientific Atlanta). The evaluationapplication 512 may then determine whether to recommend either of theother devices in the subscriber’s accounts as indicated above, such asbased on comparable capabilities (e.g., the Motorola MR-DVR may becomparable in capabilities or configuration as far as content deliveryis concerned, and hence may be a viable candidate). In this regard, theMAC address may also feasibly be used to determine device configuration.For example, part of the MAC address or range of values may correspondto a known device type or family from the manufacturer associated withthe OUI (i.e., the OUI indicates a Scientific Atlanta STB, and a secondportion of the MAC indicates a 3250-family device). The evaluationapplication 512 can then pull a pre-stored template (or obtain one froma third party, such as Scientific Atlanta) indicating generally thecapabilities of the requesting device. The evaluation application 512can then determine if any of the other devices in the subscriber’saccount have similar or sufficient capabilities with respect to one ormore predetermined attributes.

The recommendations made by the evaluation application 512 are in oneembodiment provided to users via notices generated by the notificationapplication 514.

The notification application 514 running on the OME 200 generates andprovides notifications to the client devices 206 indicating which, ifany, of the user’s other devices 206 may receive the contentalternatively (or in addition) to the content being received at therequesting device 206. The notification application 514 receivesinformation from the monitor application 510 and/or the evaluationapplication 512 indicating one or more devices in a subscriber’s networkwhich are capable of displaying the requested content (or whichrepresent an improvement or “upgrade”). The notification application 514compiles this information into one or more notices. The notices may bedelivered only to the requesting device 206, to only active orcommunicate devices within the user’s account, or all of the devices 206which are identified as being a member of the requesting user’s account(whether currently active or not).

The notifications generated by the notification application 514 are, inone embodiment, interactive in nature. For example, the notificationsmay be adapted to enable the user to select one or more of the presentedcontent delivery platforms. Suppose for example, that the notificationapplication 514 generates a notification listing the user’s requestingdevice 206, as well as a DVR 226 and STB 222 as other devices in theuser’s network. The user may then select to continue (or begin) viewingthe requested content on the requesting device 206, as well asoptionally select to have the content delivered to either or both theDVR 226 and STB 222 (or one of those devices, and not the requestingdevice 206).

As indicated above, the notification may, in one embodiment, be of thetype described in co-owned, co-pending U.S. Pat. Application Serial No.11/706,620 entitled “Methods and Apparatus for Content DeliveryNotification and Management” previously incorporated herein. Asdiscussed therein, the notification application 514 may generatenotifications which enable users one or more choices, such as, choosingthe delivery platform, scheduling delayed delivery, canceling a request,etc. Further, the notification application 514 may work in conjunctionwith the monitoring application 510 to determine whether the network hascapacity or bandwidth available to service the request at each of theuser’s devices, and may generate notifications which alert thesubscriber of a potential unavailability of requested content on variousones of these devices 206.

The notifications generated by the notification application 514 mayfurther provide a projected delivery or availability time for therequested content (either at the requesting client device 206, or atanother available device).

It is further appreciated that a master scheduler application (notshown) may also be run on the processor 506 of the OME 200. The masterscheduler application enables the user to select one or more of the CPE106 associated with the user’s subscriber account for delivery of therequested content, and schedule delivery of content thereto (asdiscussed above). In one embodiment, the master scheduler functionalityis included within the aforementioned notification application 514,which is configured to receive and process delivery scheduling commandsor input, thereby enabling a user to enter a specific date and/or timefor delivery of content for individual ones of the available clientdevices 206. For example, the user may be able to specify delivery ofcertain content to their DSTB/HDTV in the living room from 8:00 pm to11:00 pm, and then at their second receiver/smaller monitor in thebedroom from 11:00 pm through 8:00 am. As described elsewhere herein, anextant content delivery session may also be moved seamlessly between thetwo environments, such as by e.g., adding the second device to anexisting IP unicast or multicast, and then removing the first device atthe prescribed time (e.g., via SIP multi-party “conferencing” or similarprotocols).

State Information

In one embodiment, a network entity (e.g., a REST search/recommendationentity such as that described in U.S. Provisional Pat. ApplicationSerial No. 61/256,903 entitled “METHODS AND APPARATUS FOR PACKETIZEDCONTENT DELIVERY OVER A CONTENT DELIVERY NETWORK, previouslyincorporated herein) may be utilized to provide state transfercapabilities between devices. As used herein, the term “state” referswithout limitation to the status, temporal, or other context associatedwith one or more content elements. For example, the aforementionedexemplary REST search/recommendation entity enables a user to “bookmark” content at a first device, and have the content moved to adifferent place in the premises and/or a different device. In otherwords, the state of the content at the first device is identified andtransferred (as metadata) along with the content, to a second device.The second device may then begin playback of the content according tothe state identified in the metadata. Other states may be transferred aswell including e.g., a pause, StartOver, etc. function. The statetransfer capabilities may be automatic (such as upon teardown) and/orsubject to user request. The above-disclosed state transfer capabilitiesmay be affected via a uniform user interface (present on each of thedevices) and enable content state transfer across multiple, differentplatforms.

In one embodiment, the general state transfer concepts are of the typediscussed in co-owned U.S. Pat. No. 7,486,869 issued Feb. 3, 2009 andentitled “System And Method For Controlling A Digital Video Recorder OnA Cable Network”, which is incorporated herein by reference in itsentirety. As discussed therein, signaling associated with the answeringor initiation of a digital telephone call by a digital telephonesubscriber is used to issue commands to a digital video recorder (DVR).For example, a signal is generated by a first device at a first event(such as e.g., a signal is generated when a telephone is enters an“off-hook” state), the signal is sent to a second device indicating theevent (such as e.g., a DVR). In response to receiving the signal, thesecond device takes some action with respect to content (e.g., pausingor initiating a recording of the content at the DVR). A second signalreceived from the first device may, in one embodiment, be generated onthe happening of a second event, transferred to the second device andcause a second response at the second device. The aforementioned statemessages may be sent over an out-of-band channel/path between thedevices.

In another embodiment, the aforementioned state transfer capabilitiesmay be utilized to provide state transfer operations between legacydevices and IP capable devices by e.g., utilizing a VOD mechanism tomove a state message there between. Various other approaches may be usedas well consistent with the present information.

Client Device Implementations

Referring now to FIG. 6 , an exemplary implementation of a client device206 is given. The exemplary client device 206 includes a networkinterface 602, a processor 604 and associated storage 606, and aplurality of back end interfaces 608 for communication with otherdevices. As discussed above with respect to FIGS. 1-1 d and 2-2 b , theclient devices 206 may comprise any number of device types including,for example, CPE 106 (such as DSTB, MB, CPD, etc.), PVR, DVR, networkDVR, computer devices (such as PC and laptop computers), and mobiledevices (including PMD and mobile telephones). The device 206 of FIG. 6is intended to represent the features of each of the aforementioneddevices generally, and any design or configuration changes between thevarious types of devices will be readily appreciated by those ofordinary skill given the present disclosure.

The illustrated client device 206 can assume literally any discrete formfactor, including those adapted for desktop, floor-standing, orwall-mounted use, or alternatively may be integrated in whole or part(e.g., on a common functional basis) with other devices if desired.

It will also be recognized that the device configuration shown isessentially for illustrative purposes, and various other configurationsof the client devices 206 are consistent with other embodiments of theinvention. For example, the device 206 in FIG. 6 may not include all ofthe elements shown, and/or may include additional elements andinterfaces such as for example an interface for the HomePlug A/Vstandard which transmits digital data over power lines, a PAN (e.g.,802.15), Bluetooth, or other short-range wireless interface forlocalized data communication, etc.

The network interface 602 of the illustrated client device 206 receivescontent and/or data from the content distribution network (e.g., HFC,HFCu, satellite, etc. network 101). In one embodiment, the networkinterface 602 may comprise a traditional video RF front end (e.g.,tuner) adapted to receive video signals over, e.g., one or more QAMs.For example, the RF front end may comprise one or more tuners, ademodulator, decryption module, and demultiplexer of the type well knownin the art, although other configurations may be used. A wideband tunerarrangement such as that described in co-owned and co-pending U.S. Pat.Application Serial No. 11/013,671 entitled “Method and Apparatus forWideband Distribution of Content” filed Dec. 15, 2004 and incorporatedherein by reference in its entirety, may also be utilized, such as wherethe content associated with one or more program streams is distributedacross two or more QAMs. The network interface 602 may, alternativelycomprise any number of a mechanisms for the receipt of content and/ordata.

Additionally, the network interface 602 modulates, encrypts/multiplexesas required, and transmits digital information for receipt by upstreamentities such as the CMTS or a network server. Programming data may alsobe stored on the device storage unit 606 (discussed below) for laterdistribution by way of the video interface, or using a Wi-Fi interface,Ethernet interface, FireWire (IEEE Std 1394), USB/USB2, or any number ofother such options.

The network interface 602 may further comprise a cable modem (CM) of thetype known in the art. In this fashion, and content or data normallystreamed over the CM can be received and distributed by the clientdevice 206, such as for example packetized video (e.g., IPTV) orbroadband Internet data.

Programming and other types of data including pictures, video, music orMP3 files, software applications, metadata files, etc. may also bereceived by way of the various digital interfaces in the client device206. These data may be stored locally (e.g., in the storage unit 606) oreven on a device or network agent in communication with the clientdevice 606, for later use by a user as is discussed in co-ownedco-pending U.S. Pat. Application Serial No. 11/378,129 filed Mar. 16,2006 and entitled “METHODS AND APPARATUS FOR CENTRALIZED CONTENT ANDDATA DELIVERY”, previously incorporated herein by reference in itsentirety. As discussed therein, a user may receive a video, JPEG, etc.MP3 file, from a friend’s smartphone or PMD, which can then be “pushed”to a corresponding interface on the client device 206, wherein the datais stored on the mass storage device 606. Similarly, video data from aconnected DVD player/burner might be streamed from the player to thedevice 206 for storage thereon (or distribution via yet anotherinterface, such as via the Ethernet interface to another client device206).

The mass storage device 606 of the illustrated embodiment comprises aSerial- ATA (SATA) or Ultra-ATA (also known as Ultra-DMA, orATA-4/5/6/7) hard disk drive for the operating system and contentstorage of at least 300GB, although higher capacities and even RAIDarrays may be used for this purpose..

A registration application 610 (located in the storage unit 606 orprogram memory) is run on the processor 604 of the client device 206.The registration application 610 is utilized by the client device 206 toprovide information regarding the device and the subscriber to the OME200 and/or billing system 204. In one embodiment, the device 206identifier (e.g., MAC address) is manually entered by a technician orother MSO personnel. For example, the user may, via telephone, email,text message, etc. give an operator a MAC address to be added to his/heraccount. Alternatively, a technician may connect the device 206 to theuser’s premises and facilitate its addition to the user’s account (e.g.,via a service call) using the registration application 610. In anotherembodiment, when a user plugs a client device 206 into an existing homeor premises network, a series of communications automatically occurbetween the added device 206 and one or more headend 150 entities (suchas the OME 200 and/or billing system 204) resulting in the registrationof the device 206 to the user’s account without requiring a substantialuser, operator and/or technician action or intervention.

The client device 206 is further configured to run a client application612 thereon (which may be integrated with the aforementionedregistration application, or other applications of the CPE if desired).The client application 612 enables the device 206 to receive and displaynotifications from the notification application 514, and also enablesthe user of the device to interact with the notifications. The clientapplication 612 may be further configured to analyze the client device206 capabilities, and report these to the OME 200 for storage in thedatabase 250 as device description records 256, as described elsewhereherein.

In another implementation (not shown), content and/or data may bedistributed to the client devices 206 via Worldwide Interoperability forMicrowave Access (WiMAX) transport; see IEEE Std. 802.16e-2005 entitled“IEEE Standard for Local and metropolitan area networks -Part 16: AirInterface for Fixed and Mobile - Broadband Wireless Access SystemsAmendment 2: Physical and Medium Access Control Layers for CombinedFixed and Mobile Operation in Licensed Bands”, which is incorporatedherein by reference in its entirety. For example, multiple WiMAX basestations may be established by the MSO or other content provider. One ormore of the WiMAX stations transmit programming or other content and/ordata to the client devices 206 (which may include simultaneously, so asto ensure a robust signal is received and to potentially support any QoSrequirements). In one embodiment, a client device 206 may transmitregistration information out-of-band data via WiMAX transport. In thisfashion, the WiMAX transport acts as a wireless data “pipe” in parallelto the normal DOCSIS or in-band RF channels (e.g., QAMs) transmittedover the cable or satellite distribution network.

In the context of the present invention for example, the client device206 might transmit content requests via the cable network to the server201 (which are subsequently passed to the OME 200), yet receiverequested content (at the requesting device and/or at a second device)via the WIMAX broadband interface. Alternatively, the WiMAX interfacecould be used to transmit the requests to the server 201 (via a WiMAXinterface associated with the latter), with delivery of the requestedcontent being via in-band or DOCSIS RF QAMs. The aforementioned WiMAXinterface may also be utilized by the client device 206 and/or the OME200 and billing system 204 during the registration process. Variousother permutations of the foregoing will be recognized by those ofordinary skill given the present disclosure.

User Interface

In another aspect of the invention, a substantially centralized userinterface and control device is disclosed which permits the transfer ormigration of content delivery sessions (e.g., SIP-based IPTV sessions orthe like) between two or more devices. In one implementation, the user’spremises gateway or DSTB and associated display device, or PC, is usedas the host (control) device for the user interface, the latter whichshows the various premises and “off-net” devices associated with theuser/subscriber account, and their interconnectivity (i.e., whichdevices are currently in communication with others via wired or wirelessinterfaces, etc.).

For example, “on-net” devices might include the user’s premises gatewayor CPD, DSTB, DVR, WiMAX-enabled receiver, HDTV, etc., while “off net”devices might include the user’s Wi-Fi-enabled laptop or smartphone,cellular smartphone (which may be the same device as the former), PMD,etc. As used herein, the terms “on-net” and “off-net” are used merely tohighlight the difference between services or delivery modes provided bythe MSO and those provided by an outside or third-party operator (e.g.,cellular service provider or wireless service provider), although theseterms are by no means determinative, and in fact devices can switchhosting (e.g., go from on-net to off-net, and vice versa), or bemulti-functioned. For example, a WiMAX-enabled portable receiver may beserviced by the MSO infrastructure for delivery of MSO content asdescribed elsewhere herein, or be serviced by a separate wirelessservice provider not associated with the MSO, or both.

In one variant, the control device includes a GUI functionality (e.g., amulti-touch-screen GUI, drag-and-drop, speech recognition application,or other interface/input device) allows the user to rapidly designateparticular devices for establishment of a session/delivery of content,and/or transfer existing communication sessions between capable devices(such as may be determined by the OME recommendation engine). Remotecontrol devices associated with extant devices such as DVRs, DSTBs, etc.can for example be modified to include the foregoing UI/GUIfunctionality, or a separate dedicated device provided.

In another variant, a separate centrally located “always on” device withtouch screen functionality is provided, so that the user can see thestatus and connectivity of all devices, and control the transfer ofcontent delivery sessions via the device. For example, the UI shows alldevices in premises, and touch screen and “drag and drop” functionalityallows the user to select an icon associated with a given device with anactive content delivery (e.g., SIP) session, and literally drag theirfinger to the icon of a second (and/or third) device desired to receivethe content. This drag and drop function will then be treated as theuser “OK” to transfer the session automatically as described elsewhereherein (which may also include “state” preservation functions ifdesired).

In another embodiment, a substantially network-based user interface isemployed; see e.g., the exemplary implementation described in co-ownedand co-pending U.S. Provisional Pat. Application Serial No. 61/256,903filed Oct. 30, 2009 previously incorporated herein. In this embodiment,a network entity (e.g., server) is used to manage and update UI’sgenerated on the client devices within the network, including generationof graphics, listings, etc. illustrating different device deliveryoptions as described elsewhere herein. For instance, in one scenario,the user requests delivery of a particular content element via theirIP-enabled DSTB and associated monitor. The resulting evaluation ofassociated user/premises devices produces a recommendation or listing ofother devices, which are then displayed on the UI (e.g., in a graphicalformat, table, etc.), akin to adding another “service”.

In yet another embodiment, a speech recognition and command interface ofthe type well known in the digital signal processing arts is used inconjunction with the aforementioned client device to move sessions fromone device to another. This embodiment operates substantially similar tothose previously described (e.g., remote control, display, ortouch-screen controlled), yet using predetermined commands to effectsession transfer. For example, plain language commands such as “MoveTransformers to Bedroom” or the like may be employed via the speechinterface. In one variant, the speech recognition system can be trainedby the user as to particular commands, which may be location- ordevice-based (e.g., “Move Living Room to Bedroom″ or″ Move DSTB1 toPC”), or alternatively may be context or content based (“Move [contentidentifier] to [location] or [device]”), and so forth. The contentidentifiers selected by the user may in another variant be sent up tothe OME or other entity within the network for future access or use;i.e. to allow for encoding of the metadata associated with a particularuser session “on the fly” so that the voice command interface will beoperative and recognize that particular user’s commands. For instance,one user might call the movie “Transformers” by that name, whereasanother use might say “movie on HBO” or “movie about transformingrobots”, and hence prior knowledge by the network of a given user’scommands enables the encoding specific to that user. Metadata encodedwith content may also or alternatively include several keywords (e.g.,“transformer”, “robot”, “Megan Fox”, “HBO”, etc.), which may be used bya search function or engine disposed on the client device (or thenetwork entity) to identify the relevant content element. Other commandsmay also be programmed in; e.g., “Move Transformers to Bedroom in FiveMinutes and Shut Down DSTB”, or the like.

Voice commands may also be user-specific, such that only a particularuser’s voice is operative to command session transfer (e.g., viabiometrics).

In another variant, speech or another user attribute can be used todetermine user presence/movement within a premises. This information canbe fed into the client-side application (or even transmitted to the OME)so as to allow for command-prompted or even automatic session transferwithin the premises. For example, in one scenario, the user merely says“I am here” when they desire to transfer the session to their newlocation. The speech recognition engine/command interface receives thisinput and determines where “here” is (e.g., bedroom, by virtue of thelocation of the microphone or other device receiving the voice signal),and transfers the session.

Alternatively, a sensor (such as Passive IR or the like, which may evenbe associated with another host system such as a premises securitysystem) can be used to transfer, initiate, or terminate sessions orother device functions (e.g., power up/down, tuning, etc.). Hence, whena user walks from the living room to the bedroom, the client applicationand/or OME can receive information regarding the user’s location, andmove (or replicate) the session automatically. Of course, this type ofapproach is best suited for a situation where relatively infrequentmovement occurs by very few or one individual (e.g., an older person wholives alone and does not move room-to-room very often), although it isnot so limited to such applications.

Business Models and “Rules” Engine

In another aspect of the invention, one or more computer programsrunning on the processor 406 of the OME 200 (or other entity such ase.g., server 201, BSA hub entity, client device 206, etc.) includes aso-called “rules” engine. This engine comprises, in an exemplaryembodiment, one or more software routines adapted to control theoperation of the client devices 206 (and optionally supporting networkinfrastructure) in order to achieve one or more goals relating tooperations or business (e.g., profit). Included within these areas arenetwork optimization and reliability goals, increased maintenanceintervals, increased subscriber or user satisfaction, increasedsubscription base, higher revenue or profit (e.g., from increasedadvertising revenues), more subscriber “views” of given content, higherdata download speed, increased bandwidth and responsiveness to changingdemands for bandwidth, reduction of undue QAM replication, and so forth.

These rules engine may comprise a separate entity or process, and mayalso be fully integrated within other processing entities (such as theaforementioned OME), and controlled via e.g., a GUI displayed on adevice connected to the relevant device or server. In effect, the rulesengine comprises a supervisory entity which monitors and selectivelycontrols the operation of the clients 206 at a higher level, so as toimplement desired operational or business rules. The rules engine can beconsidered an overlay of sorts to the more fundamental algorithms usedto accomplish client device recommendations (e.g., the “recommendationengine” discussed above).

For example, the OME 200 or client device 206 may invoke certainoperational protocols or decision processes based on information orrequests received from the device 206, conditions existing within thenetwork, demographic data, geographic data, user preferences, etc.However, these processes may not always be compatible with higher-levelbusiness or operational goals, such as maximizing profit or systemreliability. Hence, when imposed, the business/operational rules can beused to dynamically (or manually) control the operation of the clientprocess on the client device 206. The rules may be, e.g., operational orbusiness-oriented in nature, and may also be applied selectively interms of time of day, duration, specific local areas, or even at theindividual user level (e.g., via specific identification of the clientdevice 206 via MAC address, IP address, cryptographic hash or digitalsignature, or the like, or via user-specific or account-specific login).

For example, one rule implemented by the rules engine may comprise onlyproviding certain types or formats of programming to certain subscribersor classes of subscribers, and/or on certain ones of the subscriber’sregistered devices. As noted previously, these rules may be implementedat the device level (e.g., client device 206), or at the OME 200 (suchas by placing information regarding these rules into the database 250).A particular client device 206 may possess an MPEG-4 decoder, forexample, but the device 206 may not be recommended for delivery ofrequested programs rendered in MPEG-4 encoding, unless the subscribermeets certain criteria (e.g., “premium” subscription, etc.). Similarly,if any of the subscriber’s registered devices 206 do not possess arequired codec, CA keys, DRM, or network interface, recommendation ofthe device 206 by the evaluation application 412 may be controlled,and/or the download of the missing component/capability may berestricted to only subscribers meeting certain criteria. As indicatedabove, in one embodiment, information regarding the subscribersubscription level and other factors affecting content delivery, as wellas the rules themselves, may be stored at the database 250 andimplemented by the OME 200 (or retrieved by the OME, such as from thenetwork BSS).

Another rule might impose a moratorium or restrictions on upstream dataor information messages (e.g., SSP) or requests for content from theclient devices 206 during conditions of very heavy loading (e.g., untila certain minimum threshold of available bandwidth is present), therebyavoiding contention for bandwidth resources with “premium” services.Similarly, program-related or other processing typically done upstreamof the client devices 206 could be dynamically shifted to the devices206 under such circumstances so as distribute the processing load (andhence upstream messaging bandwidth consumed) to the client devices 206.

The rules engine may further establish that recommendations by the OME200 (i.e., recommendation engine previously described) may be limited toonly certain subscribers and/or certain types of devices 206. Forexample, the processes of monitoring, evaluating and notifying (asperformed by the monitor application 410, evaluation application 412 andnotification application 414) may be limited to only those deviceshaving a premium service level. Additionally, the aforementionedservices may be limited to only certain ones of a subscriber’s devices206, the additional devices being added to the service at a premium.

Yet another rule might impose restrictions on establishing or allocatingnew physical channels/QAMs or IP-packetized delivery sessions to thesubscriber channel requests based on device 206 profile data (e.g., thepresence or lack of a certain required interfaces, codecs, CA, DRM,etc.). As previously discussed, bandwidth/QAM resource allocation andother relevant network considerations may be used as a basis ofdetermining device 206 recommendations in a broadcast switched network.This process can also be made dynamic if desired; such as where QAMloading and similar parameters can be continuously or periodicallyre-evaluated, and the operation of the network altered accordingly. Forexample, when sufficient bandwidth is again present, the subscriber ofthe previous example may be switched over to a program stream associatedwith the higher bandwidth codec, or allocated an HD session versus SD onthe same HD-capable device (with the switch-over being effectivelyimperceptible to the subscriber).

Still further, the system may be modified such that during instances ofincreased demand on the network, certain classes of subscribers (e.g.,lower tier subscribers) may only be permitted to view content atparticular ones of client devices. In other words, as bandwidth demandincreases, certain subscribers may no longer be able to view content oncertain devices. As a result, when a requesting device 206 requestscontent, the subscriber may be restricted as to which devices areavailable, or in the extreme not be given a choice as to which device toreceive the requested content on, but rather will be immediatelydirected to a device selected by the network. Hence, under thisparadigm, the user’s available device population/delivery mode “matrix”grows and shrinks as a function of network loading.

The present invention also lends itself to various business models interms of distribution, operation, and service provision. Specifically,by having remote monitoring, configuration and provisioning capability,the service provider (e.g., MSO) is given greater flexibility in, interalia, (i) troubleshooting and repairing faults within the CPE 106 orother connected premises devices which may otherwise require a servicevisit; and (ii) changing or reconfiguring a given subscriber’s servicepackage or capabilities remotely, again obviating a service visit oractions by the subscriber while simultaneously being able to providerequested content at other ones of the subscriber’s devices 206. Forexample, as previously described, new client devices 206 are immediatelyupdated to a subscriber account (as well as removal of devices), thenprovided to the database 250, thereby allowing the OME 200 to rapidlyswitch service options on a per-subscriber or per-device basis(enhancing so-called “service velocity”).

Under the foregoing model, the MSO may also utilize the OME andsupporting processes to mitigate service outages for the subscriber. Forinstance, in one variant, the device population for a given user orsubscriber account is periodically or anecdotally scanned and evaluatedfor the then “best” alternative or second option for the user, based one.g., the output of the recommendation engine. At any given time, thesubscriber may be utilizing the “best” option, and the rules enginecould utilize the recommendation engine to rank the available options toperiodically determine the second-best option. Hence, when a devicefailure or other delivery issue of the (then) “best” option occurs, theOME would be primed to immediately swap the subscriber over to thesecond-best choice at that time, and display a notification (or generatean audible cue, etc) on the then-selected (alternative) platform (andthe failed platform, to the degree it is operable to do so) to alert theuser as to the switch and why it occurred (e.g., “Malfunction on OptionNo. 1 - Network-imposed Switched to Option 2”, or the like). Thisapproach advantageously maintains subscriber program continuity to themaximum degree possible, rather than having the subscriber staring at ablank of fuzzy screen with no explanation why.

For example, in one implementation, the ROM of each device (e.g., DSTB,gateway, CPD, etc.) might include the aforementioned alert message, sothat if it and its associated display are at least marginallyfunctional, the alert could be displayed (rather than having thesubscriber have to hunt for which platform was designated “next best” atthat moment to find the ongoing program stream).

The foregoing functionality may also be masked by other factors ordevice considerations, such as sensed availability of alternates at anygiven time (e.g., only consider then powered-up and registered devicesas viable alternatives).

In yet another aspect, the methods and apparatus of the presentinvention may be tied to additional consideration from the subscriberfor changes in service delivery. For example, incremental changes in“service quality” (including e.g., video quality, audio quality, servicecoverage or reliability, transportability of sessions, access tofeatures (such as e.g., “blended” services such as those described inco-owned and co-pending U.S. Provisional Pat. Application Serial No.61/256,903 filed Oct. 30, 2009 entitled “METHODS AND APPARATUS FORPACKETIZED CONTENT DELIVERY OVER A CONTENT DELIVERY NETWORK”,incorporated herein by reference in its entirety), access to off-netcontent, etc.), may be associated with an additional charge. In onevariant, an “unlimited” package is offered, wherein the subscriber isgiven an unlimited number of uses or “upgrades” for an unlimited (withintheir device capability profile) number of different services, all foran extra monthly premium. Alternatively, a “per use” payment model maybe employed, or a finite limit per time period for a given premium. Theuser may also “barter” for the upgrades in another variant; e.g., suchas by exchanging actions (e.g., taking a survey, reviewing a sampleadvertisement/promotion, etc.) in exchange for the “upgrade(s)” Thisapproach can also be used as a “teaser” for enhancing existingsubscriptions; i.e., by offering the subscriber enhanced capabilitiesfor a trial period, they may request an upgrade to their subscriptionlevel or addition of the service (for added cost).

Many other approaches and combinations of various operational andbusiness paradigms are envisaged consistent with the invention, as willbe recognized by those of ordinary skill when provided this disclosure.

It will be recognized that while certain aspects of the invention aredescribed in terms of a specific sequence of steps of a method, thesedescriptions are only illustrative of the broader methods of theinvention, and may be modified as required by the particularapplication. Certain steps may be rendered unnecessary or optional undercertain circumstances. Additionally, certain steps or functionality maybe added to the disclosed embodiments, or the order of performance oftwo or more steps permuted. All such variations are considered to beencompassed within the invention disclosed and claimed herein.

While the above detailed description has shown, described, and pointedout novel features of the invention as applied to various embodiments,it will be understood that various omissions, substitutions, and changesin the form and details of the device or process illustrated may be madeby those skilled in the art without departing from the invention. Theforegoing description is of the best mode presently contemplated ofcarrying out the invention. This description is in no way meant to belimiting, but rather should be taken as illustrative of the generalprinciples of the invention. The scope of the invention should bedetermined with reference to the claims.

1-43. (canceled)
 44. A computerized method of providing at least serviceto one or more computerized devices, the computerized method comprising:receiving first identifying data relating to a first computerizeddevice; utilizing the first identifying data to associate the firstcomputerized device with a user profile; receiving data representativeof user input via an application configured to run on the firstcomputerized device; utilizing the data representative of the user inputto associate the first computerized device with a first location ofpremises; subsequent to the association of the first computerized devicewith the first location, receiving data representative of a request tochange the association of the first computerized device with the firstlocation to an association of the first computerized device with asecond location; utilizing the data representative of the request to:(i) update the user profile with respect to the change and (ii) causethe change of the association of the first computerized device with thesecond location and disassociate the first computerized device with thefirst location; and providing at least one service to the firstcomputerized device at the second location.
 45. The computerized methodof claim 44, wherein the receiving of the identifying data is commencedautomatically upon data communication between the first computerizeddevice and a premises network of the premises .
 46. The computerizedmethod of claim 44, wherein the receiving of the data representative ofthe request to change the association of the first computerized devicewith the first location to the association of the first computerizeddevice with the second location comprises receiving a speech command tomove an identifier associated with the first computerized device to thesecond location.
 47. The computerized method of claim 46, wherein thereceiving of the speech command comprises receiving a speech commendspecific to a user of the first computerized device, such that only avoice of the user can initiate the change.
 48. The computerized methodof claim 44, wherein the receiving of the data representative of therequest to change the association of the first computerized device withthe first location to the association of the first computerized devicewith the second location comprises receiving, via a sensor of the firstcomputerized device data, indicating that the first computerized devicehas moved from the first location to the second location.
 49. Thecomputerized method of claim 44, wherein the receiving of the datarepresentative of the request to change the association of the firstcomputerized device with the first location to the association of thefirst computerized device with the second location comprises receivingdata indicative of a user selection via use of drag-and-dropfunctionality.
 50. The computerized method of claim 44, furthercomprising: establishing data communication between a bridge device anda premises network via use of a first communications protocol; receivingsecond identifying data relating to the bridge device via use of thefirst communications protocol; utilizing the second identifying data toassociate the bridge device with the user profile; and establishing datacommunication between the bridge device and the first computerizeddevice via a second communications protocol; wherein the receiving ofthe first identifying data relating to the first computerized devicecomprises receiving the first identifying data from the bridge viautilization of the first communications protocol, the first identifyingdata received by the bridge device from the first computerized devicevia utilization of the second communications protocol.
 51. Thecomputerized method of claim 50, wherein the first communicationsprotocol comprises at least Ethernet, and the second communicationsprotocol comprises at least an Internet Protocol (IP).
 52. Thecomputerized method of claim 44, wherein the utilizing of the datarepresentative of the request to cause the change of the association ofthe first computerized device with the second location and disassociatethe first computerized device with the first location compriseseffecting a session transfer.
 53. The computerized method of claim 44,further comprising: receiving second identifying data relating to asecond computerized device; utilizing the second identifying data toassociate the second computerized device with the user profile; andbased on sensor data indicating that the second computerized device iswithin the first location, establishing a data communication sessionwith the first computerized device.
 54. The computerized method of claim53, wherein the second computerized device comprises a mobile device,and the first computerized device comprises a premises security system.55-57. (canceled)
 58. The computerized method of claim 44, wherein theutilizing of the data representative of the user input to associate thefirst computerized device with the first location of the premisescomprises utilizing the data representative of the user input toassociate the first computerized device with a particular room withinthe premises.
 59. A computerized network apparatus, comprising: a firstinterface configured to communicate with a network; a processorapparatus; and a storage apparatus in data communication with the firstinterface and the processor apparatus and comprising at least onecomputer program, the at least one computer program comprising aplurality of instructions which are configured to, when executed by theprocessor apparatus, cause the computerized network apparatus to:receive first identifying data associated with a first computerizeddevice; utilize the first identifying data to associate the firstcomputerized device with user profile; receive second identifying dataassociated with a second computerized device; utilize the secondidentifying data to associate the second computerized device with theuser profile; determine at least one future time at which to switchprovision of a service from the first computerized device to the secondcomputerized device; and cause the switch of the provision of theservice from the first computerized device to the second computerizeddevice at the at least one future time.
 60. The computerized networkapparatus of claim 59, wherein: the plurality of instructions arefurther configured to, when executed by the processor apparatus, causethe computerized network apparatus to: establish a first datacommunication session between the first computerized device and apremises device; and the switch of the provision of the service from thefirst computerized device to the second computerized device at the atleast one future time comprises (i) establishment a second datacommunication session between the second computerized device and thepremises device, and (ii) termination of the first data communicationsession.
 61. The computerized network apparatus of claim 59, wherein:the plurality of instructions are further configured to, when executedby the processor apparatus, cause the computerized network apparatus to:establish a data communication session between the first computerizeddevice and a premises device; and the switch of the provision of theservice from the first computerized device to the second computerizeddevice at the at least one future time comprises a transfer of the datacommunication session from being between the first computerized deviceand the premises device to being between the second computerized deviceand the premises device.
 62. The computerized network apparatus of claim59, wherein the determination of the at least one future time at whichto switch the provision of the service from the first computerizeddevice to the second computerized device is based on receipt of a speechinput from a user of the first and second computerized devices.
 63. Thecomputerized network apparatus of claim 59, wherein: the receipt of thefirst identifying data associated with the first computerized devicecomprises automatic receipt of the first identifying data from the firstcomputerized device based on a startup of the first computerized device;and the receipt of the second identifying data associated with thesecond computerized device comprises automatic receipt of the secondidentifying data from the second computerized device based on a startupof the second computerized device.
 64. Computer readable apparatuscomprising a non-transitory storage medium, the non-transitory storagemedium comprising at least one computer program having a plurality ofinstructions, the plurality of instructions configured to, when executedon a processing apparatus, cause a computerized mobile device to:receive first data indicating that the computerized mobile device iswithin a first area of a premises; based on the receipt of the firstdata, initiate a session with one or more first computerized deviceswithin the first area; receive second data indicating that thecomputerized mobile device has moved from the first area into a secondarea of the premises; and based on the receipt of the second data,automatically transfer or replicate the session to one or more secondcomputerized devices within the second area.
 65. The computer readableapparatus of claim 64, wherein the receipt of the first data and receiptof the second data comprises receipt of the first and second data fromone or more passive infrared sensors.
 66. The computer readableapparatus of claim 64, wherein the plurality of instructions are furtherconfigured to, when executed on the processing apparatus, cause thecomputerized mobile device to: display a graphical user interface (GUI),the GUI enabling a user of the computerized mobile device to view astatus and connectivity of the one or more first computerized devicesand the one or more second computerized devices.